Letter of Medical Necessity Templates

Report as inappropriate Your report has been received

Description

Letter of Medical Necessity Templates document sample

Shared by: ale15912

Tags

medical necessity, Letter of Medical Necessity, Sample Letter, how to, cover letter, medical letter, letter template, Adobe Acrobat, File Format, text version

Stats

views:: 307
posted:: 6/16/2011
language:: English
pages:: 110

Public Domain

Document Sample

Proposer's Name:

RFP No: PS-1034

APPENDIX C

FUNCTIONAL REQUIREMENTS

Behavioral Health
Electronic Health Record System

Appendix C - Functional Requirements (PS-1034) Page 1 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Table of Contents
Instructions

Pre-Registration Access/Managed Care/Provider Network

Registration/Consent

Assessment/Treatment Planning

Scheduling/Appointments

Clinical Service Documentation

CPOE

Bed Management - Residential and PHF

Billing/Accounting

Administration/Reporting

Portal

Page 2 of 110
Appendix C - Functional Requirements (PS-1034)
San Luis Obispo County
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

FUNCTIONAL REQUIREMENTS RESPONSE INSTRUCTIONS

The Functional requirements set forth in this Appendix C - Functional Requirements, for the BHEHR RFP are contained in a Microsoft Excel workbook and
is designed to be a self-scoring matrix. Each requirement is designated as either "Highly Desired" (HD), or "Desired" (D). The matrix has been designed to
require a single response in the appropriate "How Met" or "Avail." column for every numbered requirement within each respective section. Only one entry
per column per numbered requirement is permitted. Proposer shall not place responses in columns that are shaded or unnumbered, alter, insert rows or add
data to the matrix.

Complete and submit information as requested for each and every required tab. The tabs are organized first by functional area and second by supporting
process. The matrix response is on the process tabs, each of which start with 1.x. (Note: the starting 1. refers to FUNCTIONAL requirements, the x refers
to the corresponding number assigned to the process in the Process Decomposition Diagram.) For each major process, please provide one or two paragraphs
on how your solution supports that process. You may provide a reference to another area in your proposal and/or this matrix.
IMPORTANT: Proposer must not leave any numbered requirement response column blank within each respective section. Failure to provide a
response to any numbered requirement will be deemed “Non-Responsive.” Multiple responses to any numbered requirement will also be deemed
“Non-Responsive.” Responses that are deemed “Non-Responsive” will result in a zero (0) point score or may, in County’s sole discretion, result in
disqualification or elimination of the proposal.

For each numbered requirement, select one of the following for Response Column "How Met". The definitions for this column are as follows:

* Standard (Std.)
Requirement can be met...
● with a feature that exists as part of the system's existing feature set
● through the use of configuration or customization tools that already exist within the system, but without any programming or changes to program
code base (e.g. using a built-in tool to build custom local forms, reports or workflows would be acceptable)
● through the use of 3rd party products bundled as part of a typical or standard installation (e.g. a 3rd party report writer)
Note: For all requirements marked as "Standard feature," fill out "Avail." column.

* Minor Modification (Min.)
Require LESS THAN 80 hrs of work: Requirement can be met...
● by spending up to 80 hours modifying or extending the proposed solution
● by making changes to the baseline product code, including the use of custom programming
● by incorporating 3rd party products that are not included as part of a standard installation
Note: All costs associated with system modifications, both one-time and on-going maintenance, must be provided as separate line items in the cost
proposal. All modifications must be fully supported by the vendor and supported in the system upgrade process.

Appendix C - Functional Requirements (PS-1034) Page 3 of 110
San Luis Obispo County
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

FUNCTIONAL REQUIREMENTS RESPONSE INSTRUCTIONS

* Major Modification (Mjr.)
Require MORE THAN 80 hrs of work: Requirement can be met...
● by spending over 80 hours modifying or extending the proposed solution
● by making changes to the baseline product code, including the use of custom programming
● by incorporating 3rd party products that are not included as part of a standard installation
Note: All costs associated with system modifications, both one-time and on-going maintenance, must be provided as separate line items in the cost
proposal. All modifications must be fully supported by the vendor and supported in the system upgrade process.

* Not Available (N/A)
Requirement is not and will not be met by proposed solution

For each numbered requirement to which "How Met" is Std., select one of the following for Response Column "Avail". The definitions for this column are

* Production (Prod.)
Feature is installed and currently being used at similar client sites as part of the standard production product.

* Beta (Beta)
Feature is installed and being used in at least one client environment (may be running in client test environment) and is scheduled to be incorporated
into standard production product by 5/31/10

* In Development (Devl.)
In development: feature is being designed or built and is scheduled for general release into standard baseline production product by 5/31/10. Design
documents may be requested.

In addition, please provide comments that may better allow the County to evaluate your response:

* Description
Provide one or two short summary paragraphs as to how indicated set of requirements are handled as a group within the system.

Appendix C - Functional Requirements (PS-1034) Page 4 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Functional Category Title Section # Description
Pre-Registration Access/Managed Care/Provider Network 3.0 Wait List
5.0 Call Intake
18.0 Referrals/Mobile Crisis
24.0 Managed Care
34.0 Provider Contract Management
35.0 Provider Network

Appendix C - Functional Requirements (PS-1034) Page 5 of 110
Functional Requirements
1.3 Wait List

Requirement How
Prior. Avail. Description
Met
1.3 Wait List: The maintenance of a roster of clients who have been deemed eligible for covered services, but cannot yet receive services due to provider or program capacity
constraints. As active clients complete or are removed from a program or service, individuals on the wait list are accepted into a program or service for treatment.
1.3.1 Managing Program Capacity: Maintaining accurate and up-to-date information on the program's capacity to provide different types of treatment to different types of
clients, and how much of the capacity was utilized during specific time frames.
1.3.1 The system shall permit authorized users to define the capacity for each program. HD
1.3.2 Managaing Wait List: Supports manual and automatic placement and movement of individuals on a list awaiting program services. For inpatient or residential
settings, this is related to 9.0 Bed Management.
1.3.2.1 The system shall maintain a wait list of clients who need to be scheduled in the next
HD
available opening
1.3.2.2 The system shall capture, maintain, and store wait list parameters for a client (e.g., how
HD
long on, when taken off, etc.).
1.3.2.3 The system shall meet all State ADP Wait List and DATAR Reporting requirements HD
1.3.3 Prioritizing Wait List: Identifies individuals, or categories of individuals, considered a higher priority for services based on acuity measures found in selected
1.3.3.1 assessmentsshall order the wait list according to a user-defined acuity measure pulled
The system
HD
from each client's assessment.

Appendix C - Functional Requirements (PS-1034) Page 6 of 110
Functional Requirements
1.5 Call Intake

How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for How Met: Select one of the following -- Std.
for Standard, Mjr for Major, Min. for Minor, N/A for Not Applicable
Requirement How
Prior. Avail. Description
Met
1.5 Call Intake: Accepting inquiries (both written and verbally) from clients and other individuals, documenting client and call information, and responding appropriately to
the inquiry on a timely basis.
1.5.1 Responding to Inquiry: Policies and procedures are established in response to inquiry on a timely basis (via telephone, letters, e-mail, fax, Internet, intranet, etc.).
This includes both routine and emergency inquiries.
1.5.1.1 The system shall capture service request related information for inquiries coming in
through a centralized 1-800-Access Line (at the time of call intake), direct contact with HD
a County clinic, or direct contact with a contract provider.
1.5.1.2 The system shall allow a user to route crisis contacts to crisis workers and requests for
HD
routine care to outpatient clinics.
1.5.1.3 The system shall capture information from client calls pertaining to complaints,
HD
grievances, appeals, and compliments, including disposition of such calls.
1.5.1.4 The system shall permit real-time data checking and data entry while a user is on the
D
phone with a consumer, prospective consumer, or related party.
1.5.1.5 The system shall provide the ability to capture, maintain, update, and report on State-
HD
mandated California Alcohol and Drug Data System (CALOMS) demographic data.
1.5.1.6 The system shall list homeless clients/patients HD
1.5.1.7 The system shall list clients/patients at imminent risk of becoming homeless HD
1.5.1.8 The system shall list clients/patients (and aggregate data) using Homeless vouchers HD
1.5.1.9 The system shall list client/patient demographic by: ZIP code and census tract HD
1.5.1.10 The system shall list clients/patients who have not received services for a specific date
HD
range
1.5.1.11 The system shall list clients/patients currently receiving Adult Protective Services HD
1.5.1.12 The system shall list all clients/patients by service program HD
1.5.1.13 The system shall list dually-diagnosed clients/patients HD
1.5.1.14 The system shall list clients/patients currently receiving services from Social Security
HD
Advocacy Team
1.5.2 Intake Screening: A determination is made if a client should be seen by the Health Agency or by another clinic/24-hour facility or County department. Screening is
facilitated by medical and financial eligibility information provided by the client.

Appendix C - Functional Requirements (PS-1034) Page 7 of 110
Functional Requirements
1.5 Call Intake

1.5.3 Call Disposition: Based on results from available information or from research or fact-finding process, inquiries or complaints are addressed and resolved.
1.5.3.1 The system shall capture the disposition of the call, including documentation of client
HD
situation and status relative to disposition decision.
1.5.4 Logging Calls: Recording information on all calls and contacts (e.g., name, phone number, primary language, reason for call, etc.)
1.5.4.1 The system shall capture and maintain all appropriate information on the call or contact
HD
(e.g. caller name, phone number, language requirement, etc.).
1.5.4.2 The system shall report the number of calls received by:
- Attributes of caller (i.e., gender, ethnicity, age, location)
- Non-crisis support
HD
- Requests for 5150s
- Assessments (child and adult)
- Inpatient admissions (child or adult; category of admiss
1.5.4.3 The system shall report the number of calls received by time frame by Adult Child and
HD
Community Emergency Services System (ACCESS).
1.5.5 Performing Tracking and Follow-up: For unresolved inquiries or complaints, call status is tracked and monitored for completion. Follow-up efforts are made to
ensure inquiries or complaints are completed or closed.
1.5.5.1 The system shall track and monitor the status of unresolved inquiries or complaints
HD
until the call is completed or the case is closed.
1.5.5.2 The system shall list clients/patients recently referred to outside services HD
1.5.5.3 The system shall list how and where client/patient was transported to the admitting
facility, including but not limited to: Law Enforcement, System of Care staff, HD
Ambulance, Referred by Organization, Self, etc.
1.5.6 Managing Quality and Performance of Process: Quality and performance of the call center is monitored and evaluated. For example, call monitoring is considered
a widely used method of quality and performance measurement.

Appendix C - Functional Requirements (PS-1034) Page 8 of 110
Functional Requirements
1.5 Call Intake

Appendix C - Functional Requirements (PS-1034) Page 9 of 110
Functional Requirements
1.18 Referrals
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.18 Referrals: The process of sending and receiving a client from one provider to another for services. This includes the tracking of outgoing and incoming referrals made
to/from the Health Agency, as well as to/from network providers, community based organizations (CBOs), and other institutions (e.g., state hospital, IMDs).
1.18.1 Incoming Referrals: Capturing and maintaining information on incoming referrals (e.g., referral source, reason for referral, client demographics, release of
information, etc.). Referrals may be from MHS Managed Care/Central Access, other County agencies or departments, community-based organizations, and
independent fee-for-service network providers.
1.18.1.1 The system shall have the capability to receive electronic referrals. HD
1.18.1.2 The system shall track clients/patients by referring organization. HD
1.18.1.3 The system shall record, acknowledge, and track incoming referrals. HD
1.18.1.4 The system shall track incoming PC 1000 referrals. HD
1.18.1.5 The system shall track incoming referral information on the Service Request Form. HD
1.18.1.6 The system shall track the referrals through the DSS 815 forms. (Note: Form is SLO
HD
County specific)
1.18.1.7 The system shall send referral confirmation when a referral has been received. D
1.18.1.8 The system shall document, track, and report on the disposition of an incoming referral. HD
1.18.1.9 The system shall automatically notify external referral sources of assessment
D
results/disposition and enrollment status.
1.18.1.10 The system shall capture patient financial liability at the time of referral. HD
1.18.2 Deciding Referral Disposition: Decision process based on established criteria, protocol, standard, etc.
No system requirements were identified specific to this process. See below.
1.18.3 Assigning Referral: For accepted client, deciding which clinician will serve as the lead therapist or counselor, and adding the client to the clinician's case load.
1.18.3.1 The system shall match client to clinician using multiple variables determined through
the selection of user-defined criteria (e.g., provider location, specialties, non-English D
language capability, etc.).
1.18.3.2 The system shall assign staff to a client /referral by a user at the time a referral is HD
received.
1.18.4 Determining Service Coverage: The type, quantity, service period, authorized clinicians, and other essential information are used to determine or substantiate
benefit/coverage in accordance with established business rules.
No system requirements were identified specific to this process.
1.18.5 Maintaining Information: Referral information is revised or updated, along with established standards and protocols.
1.18.5.1 The system shall capture, maintain, and periodically update County "211" data through
D
an electronic download or interface.

Appendix C - Functional Requirements (PS-1034) Page 10 of 110
Functional Requirements
1.18 Referrals
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.18.5.2 The system shall capture and maintain other user-defined information on community
D
resources.
1.18.5.3 The system shall capture and maintain community resource information into a
D
searchable database that can be filtered based on user-defined criteria.
1.18.5.4 The system shall store community resource information in a way that keeps these
records separate from the list of network providers, or in a separate table that has the D
same lookup and tracking capabilities of the provider referral database.
1.18.5.5 The system shall have the ability to transfer appropriate referral information to
HD
assessment and treatment plan forms.
1.18.5 External Referrals: Recording and maintaining information that client has been referred to another provider (e.g., housing, social services, and primary care). These
referrals may be within or outside of the Health Agency.
1.18.6.1 The system shall streamline sending health record information to outside providers
D
(e.g., the client's primary care provider).
1.18.6.2 The system shall have the capability to receive electronic referrals. HD
1.18.6.3 The system shall support the issuance and tracking of service referrals to Network
D
Providers.
1.18.6.4 The system shall comply with the Title 9 requirement that DUI client shall be enrolled
D
or referred to new program in/out of County within 21 days of the date of application.
1.18.6.5 The system shall validate CalOMS discharge status prior to completion of referral out. HD
1.18.6.6 The system shall document, track, and report on the disposition of an outgoing referral
(e.g, whether client was seen by the provider or organization to which she/he was HD
referred).
1.18.6.7 The system shall provide the capability for authorized users to send referrals via email
HD
or e-fax.

Appendix C - Functional Requirements (PS-1034) Page 11 of 110
Functional Requirements
1.24 Managed Care

Requirement How
Prior. Avail. Description
Met
1.24 Managed Care: This is the process of determining the necessity, appropriateness, and efficacy of services provided to clients. Managed Care includes utilization
management (UM), which involves managing the use of services through prospective, concurrent, or retrospective review of care/service. Service authorization or certification is
the process of obtaining approval for treatment or services, based on medical necessity for MHS, prior to receiving treatment/service. Without prior service authorization, a client
may be deemed not eligible, the treatment/service may not be covered, or must be paid for out-of-pocket by the client.
1.24.1 Recording Service Requests: A request for service may be received via telephone, e-mail, fax, or online. Mental health service requests are documented on the
Service Request Form.
1.24.1.1 The system shall capture all the information in the Service Request Form. HD
1.24.2 Determining Authorization: Deciding whether to authorize a service request based on established criteria or standards (e.g., medical necessity and financial
eligibility). For medical necessity, authorization decisions are based on acuity information collected through the Service Request Form. For financial eligibility,
authorization decisions are based on determining if a client meets payer or program requirements or thresholds.
1.24.2.1 The system shall support authorizations for treatments and services. HD
1.24.2.2 The system shall support authorizations for inpatient psychiatric services (PHF), mental
HD
health day treatment, and Therapeutic Behavioral Services (TBS).
1.24.2.3 The system shall provide the ability to list the services for which the client/patient is
D
eligible and authorized to enroll.
1.24.2.4 The system shall maintain and track service authorizations according to client funding.
This will include:Medi-Cal, Medicare, Healthy Families, Medically Indigent Adult HD
(MIA), other.
1.24.2.5 The system shall capture patient financial liability at the time of authorization. HD
1.24.2.6 The system shall permit for the issuance, letter generation, tracking and closing of
HD
internal authorizations that the County issues for clients served at County clinics.
1.24.2.7 The system shall permit for the issuance, letter generation, tracking and closing of
authorizations received from health plans and managed care companies authorizing HD
services rendered by County staff.
1.24.2.8 The system shall permit for the issuance, letter generation, tracking and closing of
authorizations that the County issues to providers in the provider network as part of the HD
County's role as a Medi-Cal health plan.
1.24.2.9 The system shall support the setting of service limits for each type of authorization,
including but not limited to number of visits or days, number of client or clinician
HD
service hours, number of days or weeks, specific service codes, and/or specific dollar
limits.

Appendix C - Functional Requirements (PS-1034) Page 12 of 110
Functional Requirements
1.24 Managed Care

Requirement How
Prior. Avail. Description
Met
1.24.2.10 The system shall support the definition and enforcement of authorization rules that
lockout the provision of services to a client based on any user-defined HD
service/client/patient/provider/payor combination.
1.24.2.11 The system shall allow for the issuance, letter generation, tracking and closing of a
HD
variety of authorization types (e.g. acute inpatient, client/patient, outpatient).
1.24.2.12 The system shall compare documented services provided to authorized amounts and
notify providers and utilization managers of remaining balances and impending HD
authorization expirations.
1.24.2.13 The system shall lockout (during authorization) individual/organizational/private
provider services according to the service limits established for that type of HD
authorization or in the case of Medi-Cal/Medicare crossover cases.
1.24.2.14 The system shall permit authorized staff to override lockouts. HD
1.24.2.15 The system shall permit authorized staff to add, change, or delete services within an
D
individual authorization.
1.24.2.16 The system shall permit authorized staff to print or display a bilingual Notice of Action
D
(NOA) and other service denials to clients/patients based upon coded reasons.
1.24.3 Completing Treatment Authorization Requests (TARS): Completing State-mandated Treatment Authorization Request forms (for Fee For Service and SD/MC
inpatient services). The MHP authorizes psychiatric inpatient hospital service admissions, continued stay services and administrative days for all Medi-Cal recipients
based on county of residence. Emergency admissions are exempt from prior authorization. However, the hospital must notify the MHP in the recipient's county of
residence within 24 hours of admission. If notification is not received within 24 hours, the MHP may deny the hospital stay.
1.24.3.1 The system shall support the State of CaliforniaTreatment Authorization Request
(TAR) process per insurance and payer requirements, including but not limited to:
HD
developing the TAR, tracking the status of the TAR (e.g., pending, denied, or
approved), and tracking the history of all TARs.
1.24.3.2 The system shall permit authorized staff to print or display the Service Authorization
HD
and/or Treatment Authorization Request (TAR).
1.24.4 Managing Utilization: Proactively ensuring appropriate use of services, including establishing medical necessity, obtaining or requiring prior authorizations,
obtaining treatment authorizations, and performing prospective/ concurrent/ retrospective utilization review.
1.24.4.1 The system shall identify services that can and cannot be reauthorized. HD
1.24.4.2 The system shall list services for which the client/patient is authorized. HD

Appendix C - Functional Requirements (PS-1034) Page 13 of 110
Functional Requirements
1.24 Managed Care

Requirement How
Prior. Avail. Description
Met
1.24.4.3 The system shall track prospective clients/patients who have been authorized for
HD
services but who have not yet been evaluated or assessed.
1.24.4.4 The system shall update (renew) client/patient record and authorize additional services
HD
or treatment when required for qualified clients/patients.
1.24.4.5 The system shall track authorizations issued by third parties (e.g., Administrative
D
Services Organization (ASO) and Fee-For-Service (FFS) in-patient hospitals).
1.24.4.6 The system shall provide the ability for a user to verify that a program, service, or plan
D
has been authorized.
1.24.4.7 The system shall permit staff to enter narrative comments regarding authorized
HD
treatments or services.
1.24.4.8 The system shall automatically alert the appropriate users (e.g., the authorizing agent,
HD
network provider) when authorized services have been depleted.
1.24.4.9 The system shall prevent the approval and billing of authorization requests from
Network Providers requesting authorization for intern services for Medi-Cal eligible HD
children and Medi-Cal eligible adults.
1.24.4.10 The system shall permit authorized users to suspend authorization of services based on
HD
Medi-Medi rules.
1.24.5 Managing Network Providers: The Health Agency functions as a health plan for Medicaid mental health services. In this capacity, the County contracts with
individual providers in the community who have applied and been accepted as Health Agency network providers. These network providers have signed contractual
agreements that specify service, documentation, claims, reimbursement, and reporting terms and conditions. [See 35.0 Provider Network Management]
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 14 of 110
Functional Requirements
1.34 Provider Contract Mgmt

Requirement How
Prior. Avail. Description
Met
1.34 Provider Contract Management: Provider contract management involves the process of monitoring contractual agreements between service organizations,
providers, and various agencies (e.g., State, EOC, CHC) that facilitate service delivery and financial obligations. A contract is a legal, binding agreement that
stipulates terms and conditions between the County and another party. One of the major objectives for contract management is the development of a business
partnership with providers to ensure the delivery of quality services, proper reimbursement, risk mitigation, facilitation of administrative functions (e.g.,
authorizations, claims), and availability of funding.

1.34.1 Establishing Contract Criteria/Requirements: There are certain requirement criteria, terms, or conditions that the contract stipulates, which may include review of
parties, mental health services provided, location of services, policy/procedures, credentialing standards, certification standards, medical records, no recourse against
client, liability coverage, marketing, client grievance, arbitration, assignment/delegation, offset, hold harmless, effective dates, provider responsibility, payment
arrangement, and term and termination. Contracts can be categorized as clinic or 24-hour facility. With any appropriate provisions that requires contractors to
participate in federal/state audits and/or compliance requirements.
No system requirements were identified specific to this process.
1.34.2 Executing Contract Negotiation: A key challenge in contract negotiation is to balance cost, quality, risk, and care management. The success of contract negotiation
depends on many factors, which may include these strategies: be persuasive, aim high but realistic, prepare thoughtfully to achieve goals, and having accurate and
reliable data.
No system requirements were identified specific to this process.
1.34.3 Maintaining and Tracking Contract Status: Contract maintenance involves keeping contract terms and conditions accurate, up-to-date, and in compliance with
applicable rules and regulations. Track contracts with network providers and CBOs based on clinical outcome measures defined by the program-- measures depend on
type of program. Includes tracking the arbitration/dispute progress, insurance requirements, quality and utilization performance, financial condition (reimbursement,
payment, cash flow), licensure status and other factors important in monitoring provider contract-compliance.
1.34.3.1 Since the County has multiple contracting practices with organizational and individual
members of its provider network, the system shall support multiple contractor
agreements that include services funded by multiple payors with differing benefit HD
designs and multiple provider reimbursement systems such as case rate, fee for service,
capitation, and fixed fee payments.
1.34.3.2 The system shall maintain a Rate schedule for internal providers. HD
1.34.3.3 The system shall maintain a Rate schedule for external providers. HD
1.34.3.4 The system shall record and track communications with provider organizations and
individual clinicians, such as notes related to provider requests, complaints, and HD
contacts initiated by County staff.

Appendix C - Functional Requirements (PS-1034) Page 15 of 110
Functional Requirements
1.34 Provider Contract Mgmt

Requirement How
Prior. Avail. Description
Met
1.34.3.5 The system shall indicate that the provider has been sent current handbooks and other
D
materials.
1.34.3.6 The system shall indicate receipt of required documentation from provider. D
1.34.3.7 The system shall support a centralized repository for all contract-related templates and
D
documentation (e.g., contract templates).
1.34.3.8 The system shall maintain all required information on each contract being managed
(e.g., contract status, term/duration, contractor information, financial information, D
amendment information, termination date and reason).
1.34.3.9 The system shall allow the design and implementation of workflows specific to the
D
type of contract being managed.
1.34.3.10 The system shall provide an audit capability that tracks all revisions and/or changes to
D
an original approved contract.
1.34.3.11 The system shall generate and provide reminders for events requiring user attention
(e.g., contracts pending renewal, fee schedule changes, deadlines for submitting D
information, invoice approval).
1.34.3.12 The system shall reconcile contract amount (e.g., invoices, payments) with amount
D
encumbered for that contract.
1.34.3.13 The system shall provide a complete revision history to an approved contract package
D
upon request.
1.34.3.14 The system shall incorporate workflow to design, implement, and manage standardized
D
processes for contract management.
1.34.3.15 The system shall provide a checklist of all requirements that must be met before a
contract is approved or that are needed to ensure that a contract will continue in force D
(e.g., licensing / credentialing requirements needed for Medi-Cal contracts.)
1.34.3.16 The system shall generate and provide alerts when specific contract requirements are
D
not being met for contract approval or renewal.
1.34.3.17 The system shall provide a notification when a contractor’s date of certification
D
approaches expiration, has expired, or been revoked.
1.34.3.18 The system shall provide a notification when a contract approaches expiration, has
D
expired, or been revoked.
1.34.3.19 The system shall support configurable workflow to route contract request and/or
D
contract electronically to obtain required approvals.

Appendix C - Functional Requirements (PS-1034) Page 16 of 110
Functional Requirements
1.34 Provider Contract Mgmt

Requirement How
Prior. Avail. Description
Met
1.34.3.20 The system shall provide for electronic approval of contract request and/or contract. D
1.34.3.21 The system shall permit an approver for a contract request and/or contract to delegate
D
his/her approval authority as needed.
1.34.3.22 The system shall provide the capability for an authorized user to query the status of a
D
specific contract request and/or contract.
1.34.3.23 The system shall provide the capability for authorized users to create and maintain
D
blanket contracts with releases.
1.34.4 Maintaining History: Establishing and maintaining historical and current fee schedules.
1.34.4.1 The system shall retain historical rate information. HD

Appendix C - Functional Requirements (PS-1034) Page 17 of 110
Functional Requirements
1.35 Provider Network Mgmt

Requirement How
Prior. Avail. Description
Met
1.35 Provider Network Management: The purpose of provider network management is to ensure that the proper mix of providers (clinicians) is available to deliver necessary,
covered services to clients throughout the service area. Network management involves determining client needs, screening potential provider applicants, verifying potential
provider applicants’ credentials, license, and qualifications, writing contracts, ensuring contract compliance, and re-credentialing and renewing provider contracts as appropriate
to maintain the provider network.
1.35.1 Determining Client Needs: Determining and understanding the needs of Clients in the service area, including behavioral and clinical service, care, or treatment
needs, language(s) spoken, cultural considerations, and geographic location. Includes producing profiles on Clients by program, primary language spoken, and zip
code.
No system requirements were identified specific to this process.
1.35.2 Establishing Provider Network/Panel: Determining the type(s), quantity, location, and desired education, experience, professional qualifications, and attributes of
providers who will deliver services, care, or treatment to clients. Network providers represent a range of specialties (e.g., psychology, psychiatry) and sub-specialties
(e.g., child psychology and child and adolescent psychiatry). Using a ratio of providers to clients is one way to determine network provider requirements. A database
of providers is maintained to identify gaps in service area needs.
No system requirements were identified specific to this process.
1.35.3 Assigning Providers: Assigning a provider to a client based on client need and network provider availability. In the future, it is envisioned that following the
assessment, referral process, and eligibility process, a client will be able to search for providers by specialty, gender, language spoken, and geographic location (e.g.,
zip code) via the County Portal. See 11.0 Portal.
1.35.3.1 Following the assessment, referral, and eligibility processes, the system shall support a
client's ability to conduct an online search for providers by specialty, gender, and D
geographic location (e.g., zip code) - Also see 11.0 Portal
1.35.4 Screening Providers: At this time, the County does not recruit providers. Rather, potential applicants initiate contact with the County which then conducts an initial
screening that includes: requesting a CV, checking licensure status with applicable professional Board, and contacting Program Supervisors at each clinic via e-mail
to request feedback on potential applicants based on prior knowledge of the individual or previous experience working with the individual.

No system requirements were identified specific to this process.
1.35.5 Sending Application Packet: Sending an application packet to potential providers who have successfully completed the screening process. The application packet
includes a Scope of Practice form, Reference form, and Rate Schedule.
No system requirements were identified specific to this process.
1.35.6 Reviewing Potential Applicants: Reviewing the completed packet to see if it meets Mental Health policy requirements.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 18 of 110
Functional Requirements
1.35 Provider Network Mgmt

Requirement How
Prior. Avail. Description
Met
1.35.7 Verifying Credentials (Outsourced): The County uses Med Advantage as its credentialing verification organization (CVO). The County sends a copy of the license,
insurance face sheet, and application to the CVO which verifies DHHS (exclusions list), National Practitioner Data Bank (NPDB) malpractice judgments and lawsuits,
Drug Enforcement Administration (DEA) number, licensing Board, malpractice insurance (litigation and claims), and education and training.
No system requirements were identified specific to this process.
1.35.8 Verifying Qualifications (In-House): Verifying professional references, call coverage, adequate insurance limits, disciplinary actions, requests explanations, and CV.
No system requirements were identified specific to this process.
1.35.9 Reviewing and Deciding: Reviewing all documentation and deciding whether to negotiate a contract with the provider.
No system requirements were identified specific to this process.
1.35.10 Preparing Contract: Drafting a contract using a MS Word template, inserting provider-specific terms and conditions as appropriate. The contract may include
quantitative and qualitative performance metrics to which one or both parties must meet.
No system requirements were identified specific to this process.
1.35.11 Fulfilling Contractual Obligations: County and network provider fulfill all contractual obligations (e.g., timely completion of documentation and timely
reimbursement). May include monitoring provider performance according to performance metrics established during contract negotiations.
No system requirements were identified specific to this process.
1.35.12 Maintaining Provider Relations: Monitoring and ensuring provider satisfaction via self-administered client satisfaction surveys, self-administered provider
satisfaction surveys, and following-up on client claims of inappropriate conduct.
No system requirements were identified specific to this process.
1.35.13 Maintaining Network Provider Database: Maintaining accurate and current data on provider status (e.g., provider name, type, address, ages served, therapeutic
modalities, experience with cultural groups, experience with spiritual groups, languages spoken, specialty services, specific areas of practice, and whether accepting
new referrals).
1.35.13.1 The system shall capture detailed practice information for clinicians in the provider
HD
network (including County staff clinicians).
1.35.13.2 The system shall automatically populate user-defined forms, lists, and reports from
data entered in to the provider payment database (e.g., the Public List, Mailing List, HD
Regional List, and Scope of Practice Sheet).

Appendix C - Functional Requirements (PS-1034) Page 19 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Functional Category Title Section # Description
Registration/Consent 1.0 Application/Enrollment
2.0 Eligibility
4.0 Demographic Management
7.0 Registration
8.0 ADT/Episode Management
36.0 Share of Cost/UMDAP/Sliding Scale Co-Pay

Appendix C - Functional Requirements (PS-1034) Page 20 of 110
Functional Requirements
1.1 Application Enrollment

Requirement How
Prior. Avail. Description
Met
1.1 Application Enrollment: The process of completing a group of initial administrative functions necessary to provide behavioral health services to an individual. Includes
application for services, initial intake prior to prospective client completing an application to enroll in a covered program or service. May include assessment and placement
(for DA/S).
1.1.1 Completing Enrollment Application: Prospective client or other appropriate party completes enrollment application via paper forms or online (Internet, intranet) for
the purpose of obtaining Health Agency behavioral health services. Includes gathering 3rd party payer information.
1.1.1.1 The system shall capture initial client demographic and financial information for
individuals requesting service at the time of pre-registration (for D/AS) and at the time HD
of application/enrollment (for MHS).
1.1.1.2 The system shall automatically forward all pre-registration or application/enrollment
HD
information to registration if the individual becomes an active client.
1.1.1.3 The system shall permit staff to assign clients to programs. HD
1.1.1.4 The system shall permit staff to assign funding to programs. HD
1.1.1.5 The system shall permit the embedding of an automatic link to the Megan's Law
D
website to verify status of client as a sex offender.
1.1.1.6 The system shall permit authorized staff to print or display language specific bilingual
(English and Spanish) enrollment letters, provider change letters, or other letters as HD
identified.
1.1.1.7 To ensure compliance with Title IX, the system shall flag staff that a DUI client must
be enrolled or transferred to a new program in/out of County within 21 days of the date D
of application. (D/AS only)
1.1.1.8 The system shall support client kiosks (in waiting room areas) with computer access
D
that allow clients to enter application data themselves
1.1.2 Submitting Enrollment Application: Prospective client or other appropriate party submits completed enrollment application in person, or via US mail, fax, e-mail,
or online (Internet, intranet), for the Health Agency to decide the appropriate disposition of the application.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 21 of 110
Functional Requirements
1.2 Eligibility

Requirement How
Prior. Avail. Description
Met
1.2 Eligibility: The process of determining whether clients/beneficiaries meet medical necessity or clinical parameters for services that can be addressed through an existing
Health Agency program or service. The process also includes financial eligibility, which involves determining if a client meets the eligibility requirements for various payer
sources.
1.2.1 Establishing Eligibility Criteria: Eligibility criteria for benefits may be based on a client's medical necessity, financial status, age, diagnosis, court referral, etc. A
client may not qualify for one program, but may qualify for an alternative program, depending on payer-specified criteria.
1.2.1 The system shall permit users to define program-specific clinical eligibility criteria HD
1.2.2 The system shall automatically alert staff when a client has met clinical eligibility
HD
criteria that qualifies them for a specific program.
1.2.2 Obtaining Client's Eligibility Information for Payment: Client or other appropriate party provides eligibility information, which is available during the enrollment
process. Eligibility data may include the client's total benefit package information.
1.2.2.1 The system shall indicate whether client has provided proof of income. HD
1.2.2.2 The system shall support eligibility determination for: Medi-Cal HD
1.2.2.3 The system shall support eligibility determination for: Drug Medi-Cal HD
1.2.2.4 The system shall support eligibility determination for: Medi-Cal/Medicare crossover HD
1.2.2.5 The system shall support eligibility determination for: Medicare HD
1.2.2.6 The system shall support eligibility determination for: Grant and contract funding HD
1.2.2.7 The system shall support eligibility determination for: General Relief HD
1.2.2.8 The system shall support eligibility determination for: CalWORKs/CalWIN HD
1.2.2.9 The system shall support eligibility determination for: Healthy Families HD
1.2.2.10 The system shall support eligibility determination for: Private insurance HD
1.2.3 Electronically Verifying Eligibility: Accessing the Medi-Cal Eligibility Data System (MEDS) to determine if a client is eligible to receive Medi-Cal services. Also
includes providing online, real-time eligibility verification for non-Medi-Cal payers who support this capability.
1.2.3.1 The system shall support a real-time interface to the State MEDS database to view the
current status of a client's eligibility at any time during the client course of treatment HD
(e.g., during the billing process).
1.2.4 Downloading Electronic Eligibility Data: Periodically downloading electronic eligibility data from payers and plans, including Medi-Cal and Medicare Parts A & B.
1.2.4.1 The system shall support periodic (i.e., monthly) down-loading of the Medi-Cal
HD
Eligibility Determination System (MEDS) files from the State.
1.2.4.2 The system shall support eligibility loading for Medicare. HD
1.2.4.3 The system shall support eligibility loading for all health plans and insurers with whom
HD
the County contracts.

Appendix C - Functional Requirements (PS-1034) Page 22 of 110
Functional Requirements
1.2 Eligibility

Requirement How
Prior. Avail. Description
Met
1.2.5 Verifying and Updating Medi-Cal Eigibility and Share of Cost Information: Automatically verifying and updating each client's Medi-Cal eligibility and share of
cost balances in the Medicaid Management Information System (MMIS) using the most recently downloaded state MEDS file.
1.2.5.1 When the State MEDS system has been accessed, the system shall update the
HD
Eligibility Verification Code (EVC) in a client's Medi-Cal insurance record.
1.2.6 Verfying Benefits: Collecting enrollee eligibility information and allowing staff to verify benefits through a variety of mechanisms for Medicaid, Medicare and
Private Insurance clients.
1.2.6.1 The system shall verify against all downloaded eligibility files and automatically
HD
update the benefits for which a registered client is eligible.
1.2.7 Processing Eligibility Information: Client's information is verified with established eligibility criteria to determine qualification. Also, client episode or encounter
information is cross-referenced with eligibility information for appropriate authorization and payment. A client can belong to more than one reimbursement
&quot;group&quot; with respect to coordination of benefit process. Grouping can be based on criteria such as insurance, age, grant status, legislation, and so forth. If a
client is determined to be eligible, then an assignment of eligibility period is determined with begin/end date. Other eligibility information may include, Medi-Cal
mandated benefits, co-payment, deductible, co-insurance, coordination of benefit (COB), subrogation (workers compensation), exclusions, and other limits/restrictions.
1.2.7.1 The system shall automatically populate Client insurance fields when no prior
HD
eligibility has been determined.
1.2.7.2 The system shall automatically update Client insurance information when the eligibility
HD
status has changed, including retro-active updates for clients previously served.
1.2.7.3 The system shall provide recommendations as programs/plans to fund services
HD
provided to a client based on client needs, financial ability, and Medi-Cal eligibility.
1.2.7.4 The system shall support eligibility processing for all health plans and insurers with
HD
whom the County contracts.
1.2.8 Notifying County Staff: Alerting counselors, therapists and other appropriate parties of Medi-Cal eligibility status changes, either prospective or retrospectively.
1.2.8.1 The system shall identify clients who have lost their insurance coverage. HD
1.2.9 Notifying Clients: Eligibility result is communicated to client or other appropriate party in person, or via online, mail, telephone, fax, etc. Includes generating a
notice to the client when the client's annual financial evaluation expires.
1.2.9.1 The system will prompt staff to print County selected forms to give to the client at the
conclusion of the eligibility/financial assessment (e.g., the Advanced Beneficiary HD
Notices, PHF aftercare plan, etc).
1.2.10 Maintaining Eligibility Information: Eligibility information is maintained and updated to include client's qualification or disqualification status; includes updating
client financial and employment status; and revising eligibility criteria.

Appendix C - Functional Requirements (PS-1034) Page 23 of 110
Functional Requirements
1.2 Eligibility

Requirement How
Prior. Avail. Description
Met
1.2.10.1 The system shall maintain Medi-Cal eligibility for all individuals identified in the
monthly Medi-Cal download from the State, not just individuals who are enrolled as
HD
clients. Similar capabilities should be available for Medicare and health plans with
whom the County contracts.
1.2.10.2 The system shall permit manual on-line reviewing and updating of insurance records
for clients with special handling conditions including: a partial eligibility match
requiring investigation, Medi-Cal Share of Cost responsibility, CMSP eligibility, other HD
State aid codes, Medicare, private insurance, and Medi-Cal clients with a different
responsible county.
1.2.10.3 The system shall track client/patient eligibility to a program/service/plan. HD
1.2.10.4 The system shall maintain multiple eligibility/program statuses. HD
1.2.10.5 The system shall maintain multiple eligibility sub-programs to ensure that ineligibility
HD
for one service does not override eligibility for other services.

Appendix C - Functional Requirements (PS-1034) Page 24 of 110
Functional Requirements
1.4 Demographics Management

Requirement How
Prior. Avail. Description
Met
1.4 Demograhics Management: The collection and retention of current information that describes characteristics of individuals (e.g., clients and providers) for the purpose of
accurately and properly identifying individuals who provide, request and/or receive treatment and services.
1.4.1 Capturing, Updating, and Maintaining Client Data: Capturing data on client name, aliases, address, SSN, DOB, age, sex, race, primary language spoken,
education, and other characteristics. Correcting, modifying or updating data to reflect changes or new information.
1.4.1.1 The system shall verify client status in a given program against the defined program
HD
outcome measures.
1.4.1.2 The system shall identify to an authorized user whether a client is on probation and if
yes, capture probation Terms and Conditions and permit the user to view or print this HD
information.
1.4.1.3 The system shall capture the following mandatory data for a client: drivers license
HD
number, date of birth, date of death, and date of bankruptcy.
1.4.1.4 The system shall track Drug Court participants. (D/AS) D
1.4.1.5 The system shall provide the ability to capture, maintain, update, and report on State-
HD
mandated California Alcohol and Drug Data System (CALOMS) demographic data.
1.4.1.6 The system shall provide the ability to capture, update, maintain, and report on State-
HD
mandated CSI demographic data.
1.4.1.7 The system shall track the number of services within program against annual estimated
HD
service number.
1.4.1.8 The system shall provide a summary screen, and generate a summary sheet (or face
sheet), that contains key demographic information, administrative status (including HD
Medi-Cal/insurance eligibility), pending appointments and dates of last service.
1.4.2 Capturing, Updating, and Maintaining Clinician Data: Capturing data on clinician name, address, SSN, DOB, age, sex, race, primary language spoken, education,
licenses, credentials, and other characteristics. Correcting, modifying or updating data to reflect changes or new information. Accommodates HIPAA-compliant
The system shall Identifier by staff
1.4.2.1 National Providertrack cases (NPI). member assigned to a case. HD
1.4.2.2 The system shall capture and verify the status (active/inactive) of a provider. D
1.4.2.3 The system shall capture mandatory characteristics for all employee and contract
clinicians: name, date of registration, location, discipline, licensure, specialties, and D
category (i.e., employee, contract, community-based program).

Appendix C - Functional Requirements (PS-1034) Page 25 of 110
Functional Requirements
1.4 Demographics Management

Requirement How
Prior. Avail. Description
Met
1.4.2.4 The system shall indicate practitioner status for eligibility or good standing in
California; billing Medicaid and other payors, where applicable; and other practitioner
HD
data for all providers (both Network and County employed providers) that ensures
clinicians and practitioners are duly licensed.
1.4.2.5 The system shall support the registering, tracking and reporting on provider
HD
organizations and individual clinicians that contract with the County.
1.4.2.6 The system shall capture and track type of provider (e.g., Out-of-County, credentialed,
HD
organizational).
1.4.2.7 The system shall associate providers authorized to provide services under a given
HD
program.
1.4.2.8 The system shall capture and maintain National Provider Identifiers (NPI). HD

Appendix C - Functional Requirements (PS-1034) Page 26 of 110
Functional Requirements
1.7 Registration

Requirement How
Prior. Avail. Description
Met
1.7 Registration: The process of recording and tracking the presentation of a (DA/S) client to an outpatient setting for service. The registration process captures relevant
information about a client, his/her assigned clinician, and service type.
1.7.1 Entering/Updating Client Profile: Upon a client's arrival or check-in based on a scheduled appointment or walk-in, client information is captured or updated.
1.7.1.1 The system shall support the collection of demographic and other data that is
appropriate for the client's diagnosis, age, service setting, etc. at the time a client HD
registers for service.
1.7.1.2 The system shall be configurable to support client focused data collection (e.g., as a
client is being admitted for alcohol problems, the information system will HD
automatically prompt for particular data items appropriate to the client).
1.7.1.3 The system shall prompt the user performing client registration for missing data. HD
1.7.1.4 The system shall during the registration process cross check client name against other
HD
possible aliases.
1.7.2 Confirming the Arrival: Confirmation of the client's arrival is documented and all necessary parties are informed.
No system requirements were identified specific to this process.
1.7.3 Maintaining Visit Status: Client visit status is tracked and monitored during the visit or episode, and through discharge.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 27 of 110
Functional Requirements
1.8 ADT

Requirement How
Prior. Avail. Description
Met
1.8 Admission, Discharge, and Transfer (ADT): ADT is the process of tracking a client's admission, discharge, and transfer (change in location), and often within an
organization's health care system. ADT also keeps track of clients who are placed on leave of absence but who remain active clients. Includes transfers between settings,
programs, or clinics; special population client status tracking. Episode management is maintaining single or multiple, simultaneous episodes/statuses for clients who are
receiving services on a concurrent or overlapping basis until the case is closed.

1.8.1 Scheduling/Canceling/ Rescheduling an Admission (PHF): If known in advance, indicating in the system the anticipated date that a patient will present at the
facility for inpatient services. Changing or removing a patient who has previously been noted in the system as scheduled to arrive for inpatient services.
No system requirements were identified specific to this process.
1.8.2 Admitting a Patient/Client: Upon a client's/patient's arrival, client information is captured or updated and acceptance in to the facility for treatment is acknowledged.
1.8.2.1 The system shall support the collection of data appropriate to a client's diagnosis, age,
HD
service setting, etc. as a client is admitted for service.
1.8.2.2 The system shall support a client's admission to an organizational provider through an
HD
admission order or form.
1.8.2.3 The system shall provide the capability for an authorized user to enter a client/patient's
D
advance directive and power of attorney into the electronic record upon admission.
1.8.2.4 The system shall provide the capability for authorized users to generate and print an
admission checklist/flowsheet that includes all necessary clinical and administrative D
activities and forms required for PHF admission.
1.8.2.5 The system shall alert a designated staff member when a specific admission activity
D
involving them is due.
1.8.3 Inventorying Property: Documenting all property and effects that a patient has on their person or in their possession upon admission to the facility. Including noting
location of each article (e.g., in the room, on the unit, in a locker). At discharge or transfer, property is again inventoried to ensure patient leaves with his/her own
personal effects.
1.8.3.1 The system shall capture and track information on client valuables that are held on
HD
each unit of an inpatient facility.
1.8.4 Discharging a Patient: After the discharge order has been written and patient has been prepared to leave the facility, acknowledging in the system that the patient has
been released from the facility.
1.8.4.1 The system shall support schedules organized by provider. HD
1.8.4.2 The system shall permit authorized staff at one clinic to schedule an appointment for a D
clinician at another clinic.
1.8.4.3 The system shall provide the ability to search and find the first available appointment for a any D
given provider.

Appendix C - Functional Requirements (PS-1034) Page 28 of 110
Functional Requirements
1.8 ADT

Requirement How
Prior. Avail. Description
Met
1.8.4.4 The system shall prompt a user with suggestions for the next available appointment based on D
the master schedule and appointment parameters.
1.8.5 Transferring a Patient: Acknowledges a change in patient status or location during an inpatient stay, e.g., transfers outside of the facility, but still within the same
inpatient episode of care.
1.8.5.1 The system shall permit authorized users to transfer an admission from one
HD
organizational provider to another.
1.8.6 Maintaining Admission Status: Acknowledges a change in patient status or location during an inpatient stay, e.g., transfers outside of the facility, but still within the
same inpatient episode of care.
1.8.6.1 The system shall capture data from and for other organizational providers. HD
1.8.6.2 The system shall maintain mandatory inpatient data: date of admission, referring
provider, inpatient sponsor, outpatient authorization type, outpatient case manager, HD
date of discharge, admit and discharge diagnosis, and legal status.
1.8.6.3 The system shall generate the California Treatment Authorization Request (TAR). HD
1.8.7 Episode Tracking: Defining and tracking episodes of care for clients based on State and local definitions of episodes. This includes tracking all of the care provided
to an individual within a given service program during a given time period (e.g. a client could have mental health and drug and alcohol episodes open at the same time
and services would be tracked separately). This also includes tracking outpatient services separately from inpatient facility admissions that may occur during the same
time period.
1.8.7.1 The system shall have the ability to define and track episodes of care for clients based
HD
on State and local definitions of episodes
1.8.7.2 The system shall have the ability to track all of the care provided to an individual, by
service or program, during a given time period (e.g., a client could have mental health
HD
and drug/alcohol episodes open at the same time and services would be tracked
separately).
1.8.7.3 The system shall have the ability to track separate behavioral health episodes at the
same time (e.g., tracking outpatient services and an admission to an inpatient facility HD
during the same time period).
1.8.7.4 The system shall automatically flag episodes for closing if a user-defined, pre-
HD
determined period of no service has elapsed.
1.8.7.5 The system shall capture a client's requested guardianship and conservatorship. D
1.8.8 Crisis Tracking: Tracking crisis episode data including date and time of first contact, referral source, clinical notes about the crisis including user-defined checklists
and text-based crisis notes that allow for the recording of diagnosis, level of functioning and other relevant clinical data.

Appendix C - Functional Requirements (PS-1034) Page 29 of 110
Functional Requirements
1.8 ADT

Requirement How
Prior. Avail. Description
Met
1.8.8.1 The system shall track crisis episode data to include date and time of first contact,
HD
referral source, and clinical notes about the crisis.
1.8.8.2 The system shall provide user-defined checklists and text-based crisis notes that
HD
capture diagnosis, level of functioning, and other relevant clinical data.
1.8.8.3 The system shall track and permit easy viewing of the services provided during the
HD
crisis episode.
1.8.8.4 The system shall automatically alert the client case manager to track and monitor a
HD
crisis episode.

Appendix C - Functional Requirements (PS-1034) Page 30 of 110
Functional Requirements
1.36 SOC UMDAP

Requirement How
Prior. Avail. Description
Met
1.36 Share of Cost/UMDAP/Sliding Scale/Co-Pay/ABN: Share of cost is a mechanism by which a client's ability to pay for services received is calculated. Usually applicable
to lower income clients, fees may be calculated according to the Uniform Method for Determining Ability to Pay (UMDAP) or another method, depending on the payer source.
Sliding fee scales are calculated for DA/S (not UMDAP) based on gross income. Co-pay is the amount an insured person is expected to pay for a medical expense at the time of
the visit. An Advanced Beneficiary Notice (ABN) is a written notice made available to Medicare beneficiary Clients from the County (based on the standard government form
CMS-R-131). An ABN must be given to every Medicare patient regardless of age. For minors, the person financially responsible for payment receives a copy. An ABN is given
to a client before receiving certain items or services, and notifies the client that: Medicare may deny payment for that specific procedure or treatment. and Client will be
personally responsible for full payment if Medicare denies payment. An ABN gives the Client the opportunity to accept or refuse the item or service and protects him/her from
unexpected financial liability in cases where Medicare denies payment. It also offers a Client the right to appeal Medicare's decision.
1.36.1 Maintaining Fee Schedule and Structure: Developing annual fees for each program, using various methodologies, including creating sliding scales based on
UMDAP. Maintaining accurate and up-to-date information on payer-specific or County charges for all services rendered and programs offered to clients.
1.36.1.1 The system shall track Universal Method Determining Ability To Pay (UMDAP)
liability for billing purposes. HD

1.36.1.2 The system shall determine Universal Method Determining Ability To Pay (UMDAP)
liability by “family units” and individuals. HD

1.36.1.3 The system shall permit establishment of the UMDAP year and family members for the
family group. HD

1.36.1.4 The system shall permit client/patient payment options such as co-pays or Universal
Method Determining Ability To Pay (UMDAP) amounts. HD

1.36.1.5 The system shall be configurable to offer a variety of sliding scale fee schedules,
allowing the independent configuration of each scale according to the rules of the HD

The system shall source.
1.36.1.6 payor or funding offer a variety of sliding fee schedules using data that includes but is
HD
not limited to: family size, income, and other assets and liabilities.
1.36.2 Calculating Share of Cost: Automatically calculating a client's share of their service/program costs.
1.36.2.1 The system shall calculate differential pricing/payment based on program/plan
HD
providing the service.
1.36.2.2 The system shall indicate share-of-cost and co-pay information by plan/program. HD
1.36.2.3 The system shall track clearing of Medi-Cal share of cost for both MH and non-MH
HD
services and coordinate with State annual UMDAP requirements.
1.36.2.4 The system shall immediately update and report client/patient financial accounts to
HD
include Share-of-cost.

Appendix C - Functional Requirements (PS-1034) Page 31 of 110
Functional Requirements
1.36 SOC UMDAP

Requirement How
Prior. Avail. Description
Met
1.36.2.5 The system shall immediately update and report client/patient financial accounts to
HD
include Co-payment.
1.36.3 Determining Client’s Fulfillment of Share of Cost: Automatically calculating a client's total payments made toward his/her account and indicating to what extent
payments made fulfill their share of cost.
1.36.3.1 The system shall automatically apply a client's payment history against their share of HD
cost.system shall automatically calculate a client's fulfillment of their share of cost.
1.36.3.2 The HD
1.36.4 Calculating Sliding Fee: Automatically calculating a client's fee on the basis of client income and number of people applied to a standard (full) fee schedule.
1.36.4.1 The system shall permit a variety of client/patient income verification practices
HD
depending upon the service or program parameters.
1.36.4.2 The system shall automatically calculate sliding fees. HD
1.36.5 Generating Advanced Beneficiary Notices (ABNs): Generating ABNs and tracking whether client signatures have been obtained. ABNs mostly include standard
language but include some client-specific information such as name and medical record number.
1.36.5.1 The system shall automatically generate Advanced Beneficiary Notices (ABNs) for
HD
Medicare beneficiaries.
1.36.5.2 The system shall automatically populate Advanced Beneficiary Notices (ABNs) with
HD
client name and Medical record number.

Appendix C - Functional Requirements (PS-1034) Page 32 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Functional Category Title Section # Description
Assessment/Treatment Planning 12.0 Assessments/Evaluation
13.0 Treatment Plans
15.0 Individualized Education Plan (IEP)

Appendix C - Functional Requirements (PS-1034) Page 33 of 110
Functional Requirements
1.12 Screening Assessments Eval
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.12 Screenings / Assessments / Evaluations: Screenings, assessments, and evaluations are tools used by service providers to determine the current condition (e.g.,
psychological, psychiatric, medical, emotional, severity of abuse) of a client across a variety of parameters for the purpose of deciding appropriate intervention, treatment, and
follow-up. Review eligibility for appropriate program(s) or service(s). Assessments and evaluations provide information on persons who likely or definitively have a behavioral
health problem and/or substance abuse problem. Assessments and evaluations may be periodically re-administered to ensure that clinicians have up-to-date information on a
client's current behavioral health status. Documentation of medical history, physical exams findings, and vital signs may be included (e.g. PHF, outpatient detox).

1.12.1 Intake Assessment (MHS & DA/S): Gathering a comprehensive history about a client including current level of functioning (behaviors, symptoms, and ability to
function in a community) and needs of client per report for client as well as outside systems and agencies. This is performed by a clinician in order to determine
medical necessity (mental health, diagnosis) and/or eligibility for services. For MHS, this includes the Client and Service Information assessment (CSI); for DA/S, this
includes CalOMS, ASI and SASSI.
1.12.1.1 The system shall provide a variety of pre-defined assessment forms including, psycho-
social assessments, intake assessments, inpatient evaluations, and client/patient HD
placement evaluations.
1.12.1.2 The system shall ensure that data captured during previous non-clinical client contacts
(e.g. demographic data, address, current diagnosis) are automatically populated in HD
assessments.
1.12.1.3 The system shall capture data directly from Mobile Crisis providers so crisis info is
D
immediately available during the County's intake assessment process.
1.12.1.4 The system shall provide a link and integration of CalOMS to the system database. HD
1.12.1.5 The system shall automatically calculate a client's SASSI score from previously entered
D
data.
1.12.1.6 The system shall support the ASI Lite with standard levels of care per the American
HD
Society of Addiction Medicine (ASAM).
1.12.1.7 The system shall grant users the option to create a mental status exam using a
D
previously completed exam as a template.
1.12.2 Risk Assessment/ Management: Safety plan, Address high risk concerns (e.g., detox), Referrals to immediate treatment
1.12.2.1 The system shall flag assessments that are incomplete due to client behavior. HD
1.12.2.2 The system shall automatically flag clients at high-risk for suicide/homicide/sex
HD
offender/assaultiveness based on user-defined criteria.
1.12.2.3 The system shall restrict access to the record for specific client populations (e.g.,
HD
registered sex offenders, HIV, clients in substance abuse programs).
1.12.2.4 The system shall support the periodic tracking of patients by location according to user-
HD
defined frequency (e.g. every 5 minutes).
1.12.2.5 The system shall support Safety related to seclusions and restraints. HD

Appendix C - Functional Requirements (PS-1034) Page 34 of 110
Functional Requirements
1.12 Screening Assessments Eval
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.12.2.6 The system shall permit the creation of a variety of critical incident types that can be
HD
easily entered and retrieved.
1.12.2.7 The system shall support user-defined policies that determine procedures and
HD
responsibilities for following-up all incident types.
1.12.2.8 The system shall provide user-defined, configurable alerts that support incident tracking. HD
1.12.2.9 The system shall maintain a priority list or &quot;Hot List&quot; of at-risk
HD
clients/patients that can be accessed electronically by staff at all times.
1.12.3 History and Physical (PHF): Gathering a comprehensive health history and current health concerns in order to make medical treatment recommendations. May be
completed by a MD or nurse practitioner.
1.12.3.1 The system shall capture the periodic recording of patient vital signs according to user-
D
defined frequency (e.g. twice per day for every patient).
1.12.3.2 The system shall support the assessment of a client's developmental history. HD
1.12.3.3 The system shall maintain History & Physical assessment data for a client. HD
1.12.3.4 The system shall permit authorized users to view and report on Client/Patient-related
D
health parameters over time as part of H&P history.
1.12.3.5 The system shall support the graphical trending of information within the health and
HD
physical part of the Client/Patient record to include vital signs.
1.12.4 Nursing Assessment (PHF): Gathering a health history and conducting a brief exam.
1.12.4.1 The system shall support user-defined nursing assessments. HD
1.12.5 Interim Treatment Recommendations: Provides referral to outside resources/agencies, Outpatient therapy, Explain recommendations to client, Schedule initial
appointments (w/ doctor, group, individual, etc.), Develop interim treatment plan for first 60 days of services
1.12.5.1 The system shall automatically populate the Care Plan from the interim treatment
HD
recommendations.
1.12.6 Site Approval Team (SAT) (MHS) / Licensed Supervisor (DA/S): Assessment is presented to SAT for approval for appropriate services (MH only). NOTE: DA/S
requires approval by licensed supervisor for non-licensed clinicians.
No system requirements were identified specific to this process.
1.12.7 Assessment Disposition:
No system requirements were identified specific to this process.
1.12.8 General:
1.12.8.1 The system shall offer a forms development tool set that supports the creation of user-
HD
defined assessment forms.
1.12.8.2 The system shall allow for optional 3rd party licensed assessment tools to be
HD
incorporated into the system.

Appendix C - Functional Requirements (PS-1034) Page 35 of 110
Functional Requirements
1.12 Screening Assessments Eval
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.12.8.3 The assessment function shall be configurable to generate targeted problems for
HD
treatment and such problems can flow to the treatment planning process.
1.12.8.4 The system shall have a standard template for assessment which can be tailored to
HD
client needs and specific programs.
1.12.8.5 The system shall trigger prompts for portions of assessments that need continual
HD
monitoring (e.g., progress notes)
1.12.8.6 The system shall support collection of mandatory (required) data (e.g., clinician can't
HD
leave section blank, must indicate why information is not available.)
1.12.8.7 The system shall ensure all ancillary documentation is completed before the assessment
HD
is deemed complete.
1.12.8.8 The system shall support role-based access and authorities ensuring appropriateness of
HD
staff (e.g., ensure licensure is correct).
1.12.8.9 The system shall support the capability to declare a version (designated by section) as
HD
final (i.e., official) and prohibit further change to that version.
1.12.8.10 The system shall maintain multiple historical iterations of assessments. HD
1.12.8.11 The system shall permit an authorized user to access the appropriate assessment
D
tool/template based on the care being provided for a Client/Patient.
1.12.8.12 The system shall permit an authorized user to complete the assessment according to the
D
rules associated with that assessment.
1.12.8.13 The system shall permit an authorized user to access and view assessment data. D
1.12.8.14 The system shall permit an authorized user to review a completed assessment. D
1.12.8.15 The system shall permit an authorized user to update (append to) the assessment as
D
needed.
1.12.8.16 The system shall permit an authorized user to electronically sign the completed
D
assessment, if required.
1.12.8.17 The system shall pre-populate data from other sources or previous assessments into the
D
current assessment to reduce double data entry.
1.12.8.18 The system shall maintain completed assessments in the clinical section of the
D
Client/Patient record.
1.12.8.19 The system shall provide the capability for authorized users to develop, manage, and
D
implement standard and custom assessment templates and result formats.
1.12.8.20 The system shall allow support the ability to create user-defined reports based on
D
Client/Patient-related health parameters
1.12.8.21 The system shall provide the capability for authorized users to access and view the
D
status of periodically required screening, evaluations, and/or assessments.

Appendix C - Functional Requirements (PS-1034) Page 36 of 110
Functional Requirements
1.12 Screening Assessments Eval
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.12.8.22 The system shall support electronic versions of the assessments listed in Appendix #. D
1.12.8.23 The system shall generate notifications to a clinician when an assessment is due based
D
on workflow and documentation requirements for that type of assessment.
1.12.8.24 The system shall send notifications to members of a Client/Patient’s Interdisciplinary
D
Team (care team) when inconsistencies in assessment results are reported.
1.12.8.25 The system shall provide the capability for authorized users to schedule periodically
D
required screening, evaluations, and/or assessments

Appendix C - Functional Requirements (PS-1034) Page 37 of 110
Functional Requirements
1.13 Treatment Plans

Requirement How Description
Prior. Avail.
Met
1.13 Treatment Plans: Preparing and documenting a multi-disciplinary approach to addressing a client's problems, condition and needs for the purpose of restoring the individual to
health. Treatment plans vary by program and are based on assessments and evaluations conducted by multiple disciplines, often with client and/or family input during treatment team
meetings. Treatment plans provide documentation often required by payers to substantiate claims submitted for reimbursement of covered services. Treatment plans are re-evaluated per
program guidelines.
1.13.1 Interim Treatment Recommendations: Client and assessing clinician come up with a plan which is presented at SAT for approval. Mental Health Services prepares an
Interim plan for the initial 60 days.
1.13.1.1 The system shall automatically populate the Initial treatment plan and subsequent treatment
HD
plan reviews from CalOMS, CSI, and other assessment instruments
1.13.2 Crisis Plan: Client and Case Manager develop a Crisis Management Plan. Access to this plan must be secure yet easy to access by the care team and other providers
who have contact with the client.
1.13.2.1 The system shall provide a template to aid the client and their case manager in the development
HD
of a Crisis Management Plan.
1.13.2.2 The system shall track and report crisis episode data including date and time of first contact,
referral source, clinical notes about the crisis including checklists and text-based crisis notes HD
that allow for the easy recording of diagnosis, level of functioning, and all relevant clinical data.
1.13.2.3 The system shall alert the case manager (referral source) and appropriate clinican that a crisis
HD
contact has occurred.
1.13.2.4 The system shall permit authorized clients and providers secure access to view the services
HD
provided during the crisis episode.
1.13.3 Care Plan: Completed by treating clinician. Identifies symptoms, diagnosis, strengths, functional impairments, and recommended services. Health Agency policy states
that the Care Plan must be completed within 30 days of Interim Treatment Recommendations being approved.
1.13.3.1 The system shall provide a Care Plan that captures diagnosis codes, notes, assessment
HD
information, service types, RU's, authorization information, and staff signatures.
1.13.3.2 The system shall permit Interim treatment recommendations that were automatically brought
HD
forward to be edited or deleted.
1.13.3.3 The system shall provide the capability for an authorized user to define a care plan,
D
documenting problems identified, goals established, and care plan tasks required
1.13.3.4 The system shall provide the capability for an authorized user to update the care plan, including
D
problems, goals, and required care plan tasks
1.13.3.5 The system shall provide the capability for an authorized user to record completion of care plan
tasks, including protocols, orders, and interventions completed and follow-up and evaluation D
activities performed for a Client/Patient
1.13.3.6 The system shall provide the capability for an authorized user to document outcomes D
1.13.3.7 The system shall support the templates that can be used to create reusable care plans based on
D
protocols, "standing orders", or common interventions.
1.13.3.8 The system shall allow simultaneous review of care plans by multiple authorized users. D

Appendix C - Functional Requirements (PS-1034) Page 38 of 110
Functional Requirements
1.13 Treatment Plans

Requirement How Description
Prior. Avail.
Met
1.13.3.9 The system shall provide the capability for authorized users to maintain a list of goals for a
D
client/patient's care needs.
1.13.3.10 The system shall provide the capability for authorized users to maintain an interdisciplinary
D
problem list.
1.13.3.11 The system shall generate notifications to clinicians when care plan updates are required
D
according to the documentation rules established for that care plan.
1.13.3.12 The system shall provide the capability for an authorized user to create user-defined fields
D
and/or free text in the care plan.
1.13.3.13 The system shall provide the capability for an authorized user to create and manage
D
standardized inter-disciplinary problem lists.
1.13.3.14 The system shall support practice guidelines and evidence-based medical practices that
D
provides an alert to a user resulting from a response to an assessment query.
1.13.3.15 The system shall have the capability to provide suggestions for updates and revisions to a care
plan based on problems identified in recent clinical assessments based on best practice D
guidelines and evidence-based medical practices.
1.13.3.16 The system shall maintain an intervention list based on rules defined in the system for best
D
practice guidelines and evidence-based medical practices.
1.13.3.17 The system shall provide the capability for authorized users to re-activate a plan of care for a
discharged Client/Patient who is re-admitted to the County system (e.g., returns from an outside D
facility).
1.13.3.18 The system shall provide the capability for authorized users to re-activate a plan of care for a
D
Client/Patient who is transferred within the County system.
1.13.3.19 The system shall provide the capability for authorized users to access and incorporate external
communication and health education materials that correlate with a client/patient's care plan. D

1.13.3.20 The system shall print suggested communication and health education materials that correlate
D
with a client/patient's care plan.
1.13.3.21 The system shall generate and send a notification to physicians to when a client/patient's
D
treatment plan is to be certified.
1.13.3.22 The system shall provide the capability for an authorized user (e.g., nurse) to view the current
D
list of care plan problems.
1.13.3.23 The system shall provide a Master Service Plan that captures at least three objectives for each
HD
service type on the Care Plan.
1.13.4 Master Service Plan (MHS)/DA/S Treatment Plan: In collaboration with the client, the counselor/therapist develops goals, interventions, and desired, measureable
outcomes for each identifiable service. Includes at least three objectives for each service type on the Care Plan that must have time frames and be measurable.
1.13.4.1 The clinical data set, which offers the various statements describing the key components of the
D
treatment plan, is tailored to the appropriate target population.

Appendix C - Functional Requirements (PS-1034) Page 39 of 110
Functional Requirements
1.13 Treatment Plans

Requirement How Description
Prior. Avail.
Met
1.13.4.2 The system shall populate the treatment plan from target areas in the assessment, all field are
HD
updateable by the user.
1.13.4.3 The system shall permit some data from the treatment plan to automatically populate the
HD
case/contact note.
1.13.4.4 The system shall prohibit clinicians from entering notes without an approved treatment plan. D
1.13.4.5 The system shall alert the case manager when a new treatment plan is due according to a user-
defined time period (e.g., 30, 40, 60 or 90 days), and with the ability to defer (or "snooze") until HD
complete.
1.13.4.6 The system shall permit authorized staff at Community-Based Organizations to view treatment
HD
plan due dates for specific clients.
1.13.4.7 The system shall permit clinicians to build treatment plans for multiple target populations using
a clinical database of best practice guidelines that move clinicians through the diagnoses, D
problem, goals, objectives and interventions.
1.13.4.8 The system shall provide a Master Service Plan that captures time frames and metrics
HD
(measurable) for each objective on each service type on the Care Plan.
1.13.4.9 The system shall electronically route and authorize treatment/plan/service with notification to
HD
appropriate staff.
1.13.5 Service Plan: As needs are identified in collaboration with the client, additional services with goals, interventions, and outcomes are added.
1.13.5.1 The system shall capture additional services with goals, interventions, and outcomes as needs
D
are identified.
1.13.5.2 The system shall print pertinent information on forms and reports (e.g., Unified Service Plan,
HD
assessments).
1.13.6 Therapeutic Behavioral Services (TBS): Therapeutic Behavioral Services (TBS) are short-term, one-to-one interventions for full-scope Medi-Cal eligible children and
youth under 21 years of age who are at risk for group home placement. TBS clinician collaborates with client to identify target behaviors to be addressed by specific
behavior interventions.
No system requirements were identified specific to this process.
1.13.7 Discharge Planning (PHF): Treatment team meets daily to review medical necessity, available resources, patient readiness, discharge or aftercare plans.
No system requirements were identified specific to this process.
1.13.8 Transfer/Closing Summary/DA/S Discharge Summary: Clinician completing a brief summary of client's progress and treatment and recommendations for future
treatment.
1.13.8.1 The system shall automatically create a discharge summary using as much information as
possible from information previously captured (e.g., admission diagnosis from the face sheet, HD
mental status exam from initial evaluation, discharge meds, etc.).
1.13.9 Treatment Protocols and Care Guidelines: Best practice clinical guidelines.
1.13.9.1 The system shall generate the California Treatment Authorization Request (TAR). HD

Appendix C - Functional Requirements (PS-1034) Page 40 of 110
Functional Requirements
1.13 Treatment Plans

Requirement How Description
Prior. Avail.
Met
1.13.9.2 The system shall provide industry standard clinical libraries of best practice information on
D
treatment interventions for inquiry by clinicians.
1.13.9.3 Clinical best practice information is available for inquiry at any time during the clinical
decision-making process (e.g., when entering progress notes, during treatment planning, and D
prescribing).
1.13.9.4 The system shall permit authorized users to create, edit, and delete elements of the clinical best
D
practice guidelines.
1.13.9.5 The system shall maintain an interface to multiple best practice libraries. D
1.13.10 General:
1.13.10.1 The system shall maintain treatment plan templates that contain structure and standard content.
The system shall allow these templates to be modified as needed by an authorized user. HD

1.13.10.2 The system shall permit the creation of user-defined treatment plan data fields. HD
1.13.10.3 The system shall record and track multiple treatment and discharge plans for a single client at
D
one time, and consolidate information into a single report.
1.13.10.4 The system shall allow for the development of structured planning formats as well as the entry
HD
of free-form text.
1.13.10.5 The system shall support the use of clinical rule-bases for aiding in the development of
HD
treatment plans that are consistent with clinical best practices.
1.13.10.6 The system shall maintain an updated client service / treatment plan readily accessible to
defined users, that captures thresholds of client adherence through feedback loops and HD
automated alert capabilities.
1.13.10.7 The system shall allow for periodic updates to the existing treatment plan as client needs arise. HD
1.13.10.8 The system shall permit simultaneous viewing of multiple treatment plans on a single client. D

Appendix C - Functional Requirements (PS-1034) Page 41 of 110
Functional Requirements
1.15 IEP
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.15 Individualized Education Plans (IEPs): Each public school child who receives special education and related services must have an Individualized Education Program
(IEP). Upon referral by a school, IEP Team, BHS provides assessment (See assessment) and generates 26.5 Report. Expanded IEP Team (School and BHS) meets to review,
approve, and develop treatment goals and objectives. The Individuals with Disabilities Education Act (IDEA) requires certain information to be included in each child's IEP.
Local school districts include additional information in IEPs in order to document that they have met certain aspects of federal or state law which results in IEP forms looking
different from school system to school system.
1.15.1 Identifying Clients Who Require an IEP: Referrals to MHS are generated by the school IEP Team (the IEP team must meet to write an IEP for the child within 30
calendar days after a child is determined eligible).
1.15.1.1 The system shall provide the school with portal access to initiate an IEP referral. D
1.15.1.2 The system shall identify clients that receive IEP-driven (and billable) services. HD
1.15.2 Preparing for Individualized Education Plans: Mental health assessment completed and authorized by SAT and 26.5 Report provided to school.
1.15.2.1 The system shall alert/notify appropriate staff when the next IEP is due. HD
1.15.2.2 The system shall provide alerts/notifications specific to legal requirements related to
HD
providing Chapter 26.5 services.
1.15.2.3 The system shall track deadlines and provide alerts (e.g., no-show, reports) based on
HD
user-defined definitions and parameters.
1.15.2.4 The system shall generate an IEP service plan. HD
1.15.3 Completing MH Portion of IEP: Expanded IEP team meeting scheduled by school to review 26.5 report, Develops treatment, goals, objectives, and delivered
services specific to 26.5 definition criteria. NOTE: Need standardized form for report and documentation of goals/objectives.
1.15.3.1 The system shall populate the MH section of the IEP with appropriate information on
HD
the completed assessment, and permit individualization and formatting as needed.
1.15.3.2 The system will link goals and objectives from the current treatment plan or Master
HD
Service Plan to the IEP.
1.15.4 Providing Services: BHS provides services, tracking due dates and referral dates. The IEP is reviewed by the IEP team at least once a year, and revised as necessary.
1.15.4.1 The system shall support school personnel and county staff tracking client participation
HD
on an on-going basis.
1.15.4.2 The system shall provide a letter template (e.g., for no-shows, client d/o of treatment,
D
documentation of referral appropriateness).
1.15.4.3 The system shall prohibit billing until certain elements on the IEP are completed. HD
1.15.4.4 The system shall make billable services required fields to ensure that the provider
HD
enters information required to document billable provider services.

Appendix C - Functional Requirements (PS-1034) Page 42 of 110
Functional Requirements
1.6 Appointment Scheduling
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.6 Appointment Scheduling / Attendance: The purpose of appointment scheduling is to accept requests for, and to record, the date and time of a client's future visit(s),
reason for the visit(s), and with which service provider. Appointments can be based on a block schedule or a first come/first served basis. Appointments may be individual,
group, or a combination of individual and group. Appointment scheduling includes providing appointment schedules for all affected personnel and distributing hard copy of
appointment schedules to clients. Whether the appointment schedule is based on a centralized or decentralized model, it is designed to accommodate the availability of clients
and providers. Attendance is documenting or recording whether a client was present at a scheduled appointment, group, or event. Includes noting absences and reasons for not
being present, such as excused absences. Attendance also includes recording the presence of a client who dropped-in at a group or event for which there was no scheduled
appointment.
1.6.1 Requesting an Appointment: Request for an appointment can be made in person, via telephone, fax, or online.
1.6.1.1 The system shall offer a fully integrated appointment scheduling module that allows for
HD
rapid entry and retrieval of client appointments with staff.
1.6.1.2 The system shall support centralized scheduling for authorized staff throughout the
Department (e.g., authorized staff at Arroyo Grande clinic can see the schedule for the HD
Paso Robles clinic).
1.6.2 Maintaining Staff Schedules: Indicates dates and times individual clinicians are available to see clients.
1.6.2.1 The system shall permit authorized users to develop staff schedules. D
1.6.2.2 The system shall permit authorized users to enter staff timekeeping information. D
1.6.2.3 The system shall maintain provider profiles, including dates and times a provider is
HD
available and not available for client appointments.
1.6.2.4 The system shall display counselor/clinician caseload, including maximum, actual, and
HD
available.
1.6.2.5 The system shall permit adjustments to counselor/clinician caseloads at will. HD
1.6.2.6 The system shall permit authorized staff to schedule staff based on the census and
D
acuity regulations.
1.6.2.7 The system shall generate daily and monthly staff schedules organized by user-defined
D
locations, shift, and staff classification.
1.6.2.8 The system shall track by individual required hours worked per month, hours worked
D
within a 24-hour time period, and overtime hours worked.
1.6.2.9 The system shall provide the capability for an authorized user to enter unit-based
D
scheduling with the ability to make ad-hoc changes to staff assignments as needed.
1.6.2.10 The system shall provide the capability for authorized staff to schedule staff for
D
overtime, holidays, and leave based on staff seniority.
1.6.2.11 The system shall make scheduling information available for staff workload planning. D
1.6.3 Rostering: Setting up groups (e.g., counseling, therapy, etc) for various programs and assigning individuals to one or more group.

Appendix C - Functional Requirements (PS-1034) Page 43 of 110
Functional Requirements
1.6 Appointment Scheduling
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.6.3.1 The system shall support the creation of groups and the assignment of an individual to
HD
and removal from one or more group(s).
1.6.3.2 The system shall display real-time group availability and capacity. HD
1.6.3.3 The system shall integrate the client-signed roster with Progress Notes and
HD
automatically apply the appropriate charge(s) to the client's account.
1.6.3.4 The system shall permit a client to be associated with one or more group. HD
1.6.3.5 The system shall support multiple program-specific requirements for group structure
HD
(e.g., minimum/maximum number of clients per group).
1.6.4 Scheduling the Appointment: The individual and/or group appointment(s) is scheduled based on program availability and preferences of the client(s) and
provider(s). Information regarding appointment time, place, provider(s), and client is captured and/or updated. Requests for room, equipment, and supplies are also
1.6.4.1 scheduled. shall support schedules organized by provider.
The system HD
1.6.4.2 The system shall permit authorized staff at one clinic to schedule an appointment for a
HD
clinician at another clinic.
1.6.4.3 The system shall provide the ability to search and find the first available appointment
HD
for a any given provider.
1.6.4.4 The system shall prompt a user with suggestions for the next available appointment
D
based on the master schedule and appointment parameters.
1.6.4.5 The system shall provide a list of possible times for scheduling education, therapy, and
D
counseling appointments for a client based on the availability of required resources.
1.6.4.6 The system shall provide a program for scheduling education, therapy, counseling for a
HD
client that interfaces with staff calendar.
1.6.4.7 The system shall allow the integration of appointment scheduling with clinician
HD
maintained calendars.
1.6.4.8 The system shall permit appointment scheduling for: Individual, Group, Medication
HD
Support, Services to be Performed, and Unit of Time.
1.6.4.9 The system shall permit simultaneous appointment scheduling for multiple providers. HD
1.6.4.10 The system shall support the scheduling of recurring appointments according to user-
HD
defined frequency (e.g., weekly, biweekly, monthly).
1.6.4.11 The system shall permit over-booking groups. HD
1.6.4.12 The system shall permit double-booking clients into a time slot for a clinician. HD
1.6.4.13 The system shall coordinate client schedules into a master schedule to avoid double
HD
booking clients.

Appendix C - Functional Requirements (PS-1034) Page 44 of 110
Functional Requirements
1.6 Appointment Scheduling
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.6.4.14 The system shall automatically alert staff when an appointment would result in a client
HD
being double-booked in multiple programs.
1.6.4.15 The system shall allow for the scheduling of group rooms. D
1.6.4.16 The system shall support scheduling random drug testing. D
1.6.4.17 The system shall permit authorized users to enter and maintain resource requirements
D
for a scheduled appointment.
1.6.4.18 The system shall generate a notification to providers that includes a list of the resource
D
requirements associated with a scheduled appointment.
1.6.4.19 The system shall permit Physicians to generate daily patient list that is integrated with
D
and driven by patient appointments scheduled for a specific date.
1.6.4.20 The system shall allow an authorized user to add, delete, re-schedule, or cancel
D
individual pending and booked appointments.
1.6.4.21 The system shall generate an appointment notification based on any schedule
D
requirements associated with a physician order.
1.6.4.22 The system shall indicate the appointment type during scheduling activities. D
1.6.4.23 The system shall indicate non-available appointment times based on the schedule of
D
selected resources.
1.6.4.24 The system shall permit an authorized user to define appointment parameters based on
D
insurance, program, or payor rules for individual and group services.
1.6.4.25 The system shall alert authorized users when conflicting appointments are entered. D
1.6.4.26 The system shall permit authorized users to view clinic schedules. D
1.6.4.27 The system shall permit authorized users to view provider schedules. D
1.6.4.28 The system shall permit authorized users to view Client/Patient schedules. D
1.6.4.29 The system shall permit authorized staff at one clinic to view the appointment schedule
of a clinician at another clinic (e.g., if a patient calls the Arroyo Grande clinic about HD
their appointment at a Paso Robles clinic).
1.6.4.30 The system shall maintain standard appointment disposition types (e.g., no-show,
D
cancel, complete).
1.6.4.31 The system shall permit an authorized user to establish the priority of an appointment. D
1.6.4.32 The system shall permit an authorized user to override the priority associated with a
D
booked appointment.
1.6.4.33 The system shall maintain daily rosters of appointments. HD

Appendix C - Functional Requirements (PS-1034) Page 45 of 110
Functional Requirements
1.6 Appointment Scheduling
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.6.4.34 The system shall generate an appointment list for current and future business day(s) by
HD
various parameters.
1.6.4.35 The system shall generate appointment schedules for user-defined timeframes by:
HD
Clinic, Resource (e.g., staff, room), Client/Patient.
1.6.5 Confirming the Appointment: Confirmation of the scheduling information is provided to client, providers, and other appropriate parties. DUI clients receive a paper
copy of their appointment schedule (Title IX).
1.6.5.1 In accordance with State regulations (Title IX), the system shall have the ability to print
a paper copy of a client's schedule of appointments that can be provided to the client. HD

1.6.5.2 The system shall generate a list of scheduled appointments "x" number of business
D
days in advance that staff can use to call and confirm the appointment.
1.6.6 Reminding Patient of Appointment: In addition to hard copy patient reminders sent via US Mail, mechanisms can include e-mail, fax, and telephony approaches.
Development of an automated information system to improve patient compliance is considered.
1.6.6.1 The system shall automatically generate, upon booking of an appointment, an
card/notification letter containing instructions for the client to prepare for the D

1.6.6.2 appointment.
The system shall permit authorized users to customize the appointment notification
D
letter, including editing and formatting changes.
1.6.6.3 The system shall generate notices of pre and post appointments: Bilingual D
1.6.6.4 The system shall generate notices of pre and post appointments: Consideration to
HD
confidentiality
1.6.6.5 The system shall initiate electronic call to remind client/patient of upcoming
D
appointments: Bilingual (D/AS confidentiality concerns)
1.6.6.6 The system shall initiate electronic call to remind client/patient of upcoming
D
appointments: Consideration to confidentiality
1.6.7 Reminding Patient of Appointment: In addition to hard copy patient reminders sent via US Mail, mechanisms can include e-mail, fax, and telephony approaches.
1.6.7.1 The system shall permit an authorized user to add, delete, re-schedule, or cancel group
D
pending and booked appointments.
1.6.7.2 The system shall support pending and booked appointment list management that allows
an authorized user to add, delete, re-schedule, or cancel appointments at a clinic level. D

1.6.7.3 The system shall generate a master appointment calendar showing a client's/patient's
HD
other appointments for other programs within the system.

Appendix C - Functional Requirements (PS-1034) Page 46 of 110
Functional Requirements
1.6 Appointment Scheduling
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.6.7.4 The system shall permit staff to enter text notations and/or other pertinent information
D
to convey to the client/patient at the time the appointment is being scheduled.
1.6.7.5 The system shall indicate the client's special requirements prior to his/her appointment
(e.g., if a client should be pre-medicated prior to the appointment, primary language, D
second language, hearing impaired, physically challenged).
1.6.7.6 The system shall associate any follow-up information with the original appointment. D
1.6.7.7 For user-defined "sensitive cases," the system shall hide appointments and entire case
HD
information from all but authorized staff (e.g., electronic sealing).
1.6.7.8 The system shall automatically remind staff when follow-up appointments for a client
HD
are needed.
1.6.8 Capturing Attendance: Documenting client attendance at individual or group counseling sessions. DA/S documents client attendance via group rosters. Rosters are
automatically generated from appointments and completed at the point of service, noting clients who are present, absent, and reason(s) for absence.
1.6.8.1 The system shall capture confirmation of appointment status, including: Doctor/patient
HD
canceled, Patient no show, Appointment kept
1.6.8.2 The system shall automatically assign "Patient no show" status if there is no lab test
D
result for a client who is on the drug test schedule. (D/AS)
1.6.8.3 The system shall track client attendance at group sessions, identifying clients scheduled
HD
for group and failed to show, including the reason they failed to show.
1.6.8.4 The system shall report on the reason why a client or client(s) failed to show for group. HD

Appendix C - Functional Requirements (PS-1034) Page 47 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Clinical Service Documentation 10.0 Health Record Managment
14.0 Education/Counseling/Therapy
16.0 Notes/Documentation
22.0 Case Management

Appendix C - Functional Requirements (PS-1034) Page 48 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
1.10 Health Record Management: Health record management encompasses maintaining the organization's legal health record in a way that is compliant with Federal, State,
and local regulations and/or policies (e.g. HIPAA and 42CFR). Health record management involves recording, maintaining, retaining, and archiving client information to meet
various functions, and ensuring the record is accurate, complete, and secure.
1.10.1 Maintaining Master Patient Index (MPI): Automatically assigning a unique client/patient identifier that will be used for all client encounters and for client look-ups.
Checking for and managing duplicate identities/identifiers, and retaining only a single valid client identifier and record.
1.10.1.1 The system shall assign and maintain for each client a unique identifier. HD
1.10.1.2 The system shall allow an authorized user to search and locate the record of a client in
the MPI so that the correct person is identified before any actions are taken regarding HD
that person.
1.10.1.3 The system shall support client look-up by one or multiple identifiers (e.g., name, alias,
HD
birthdate, etc).
1.10.1.4 The system shall identify variations in name such as: Middle Initial, Driver's License
HD
No., AKA (also known as), and Soundex (sounds like)
1.10.1.5 The system shall maintain all client alias names. HD
1.10.1.6 The system shall rapidly retrieve the administrative status of any particular client (e.g.,
HD
Medi-Cal/insurance eligibility, pending appointments and dates of last service).
1.10.1.7 The system shall automatically check for duplicate clients. HD
1.10.1.8 The system shall automatically alert the user if there is a duplicate Family Number,
HD
Client/patient Number, Client/patient Name, Case Number.
1.10.1.9 The system shall prevent users from entering duplicate clients. HD
1.10.1.10 The system shall permit authorized users to override warnings of duplicate clients. HD
1.10.1.11 The system shall support photo ID with bar code capability. HD
1.10.1.12 The system shall store client/patient number(s) for other programs, as needed. HD
1.10.1.13 The system shall store client/patient number(s) for Managed Care Network. HD
1.10.1.14 The system shall store client/patient number(s) for California Department of Social
HD
Services.
1.10.1.15 The system shall store client/patient number(s) for California Department of
HD
Rehabilitation.
1.10.1.16 The system shall store client/patient number(s) for Medi-Cal Eligibility Data System
HD
(MEDS).

Appendix C - Functional Requirements (PS-1034) Page 49 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
1.10.1.17 The system shall have a record for each Client/Patient that contains a unique identifier
HD
(e.g. system-generated database key.)
1.10.2 Managing the Record: Retention, reproduction, storage, merging records including checking and merging records if a client has more than one record, and retaining
only a single valid client identifier and record. Retains all historical information.
1.10.2.1 The system shall be able to input, modify, inactivate, delete, update, display, copy, and
HD
print a unique Master Client Record.
1.10.2.2 When a client has more than one record, the system shall provide a way to merge
D
information from one record into another.
1.10.2.3 The system shall permit authorized users to merge client records. D
1.10.2.4 The system shall require user confirmation prior to merging any client demographic
D
information.
1.10.2.5 When merging duplicate records, the system shall merge information associated with
D
the incorrect client identifier(s) with the correct record and client identifier.
1.10.2.6 When merging records, the correct client identifier(s) shall be retained and the
D
incorrect client identifier(s) will be retained as void.
1.10.2.7 The system shall be able to create separate records from client records erroneously
D
merged.
1.10.2.8 The system shall retain the history of all prior Addresses, Multiple Phone numbers,
Multiple e-mail addresses, Photos, Eligibility Statuses, AKAs (also known as), Record HD
Numbers
1.10.2.9 The system shall maintain an historical audit trail on record of all changes, such as
HD
additions and deletions, by user
1.10.2.10 The system shall have client/patient data purging and archiving capability with the
HD
flexibility to set variable time parameters and limits.
1.10.2.11 The system shall support electronic retrieval of records from archive. HD
1.10.2.12 The system shall flag a sensitive or confidential client/patient case. HD
1.10.2.13 The system shall meet co-occurring disorders (dual diagnosis) data access requirements.
HD
1.10.2.14 The system shall permit configurable Clinical history screens. HD
1.10.2.15 The system shall electronically restrict access to and secure all client records. HD

Appendix C - Functional Requirements (PS-1034) Page 50 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
1.10.2.16 The system shall maintain all history of past diagnoses, treatment plans, services, and
HD
medications.
1.10.2.17 The system shall utilize the unique client identifier to mange client records. HD
1.10.2.18 The system shall automatically date and time stamps all entries in the client record. HD
1.10.2.19 The system shall provide the capability for authorized users to customize templates for
HD
medical reports that can be modified by authorized users.
1.10.2.20 The system shall have the capability to capture, retain, retrieve, and update a
HD
client/patient's legal representative as part of the client/patient record.
1.10.2.21 The system shall generate a summary of a client/patient's current demographic,
HD
financial, insurance, and clinical data (Face Sheet) as defined by County.
1.10.2.22 The system shall provide the capability for authorized users to enter a diagnosis and
effective dates, to include primary, secondary, and tertiary diagnoses for AXIS I HD
through V.
1.10.2.23 The system shall generate a notification to licensed providers to co-sign documentation
HD
prepared by unlicensed providers (e.g., students).
1.10.2.24 The system shall support the use of established templates to configure the electronic
HD
Client/Patient Record according to the clinical care being provided.
1.10.2.25 The system shall provide the capability for an authorized user to configure the structure
and fields within the electronic Client/Patient record within parameters provided by the HD
system vendor.
1.10.2.26 The system shall provide the capability for an authorized user to determine the
attributes that govern the valid values to be used within the electronic Client/Patient HD
record.
1.10.2.27 The system shall provide the capability for an authorized user to determine how the
HD
electronic Client/Patient record is organized and formatted for viewing and reporting.
1.10.2.28 The system shall provide the capability for authorized users to determine the access
privileges by role for each section in the electronic Client/Patient record to meet HD
privacy and security requirements.
1.10.2.29 The system shall provide the capability for an authorized user to enter charges related
HD
to services entered in Client/Patient record.

Appendix C - Functional Requirements (PS-1034) Page 51 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
1.10.2.30 The system shall allow County to define the business rules as to which entries in the
Client/Patient record require electronic signature for approval and when the approval is HD
needed.
1.10.2.31 The system shall provide the capability for an authorized user to access any part of the
HD
Client/Patient history according to their system-defined role.
1.10.2.32 The system shall generate a chronological, diagnosis-driven problem list. HD
1.10.2.33 The system shall restrict access to and update of a diagnosis-driven chronological
HD
problem list by system-defined user role.
1.10.2.34 The system shall support the incorporation of checklist and/or health maintenance
HD
reminders for clinicians based on Client/Patient diagnosis.
1.10.2.35 The system shall provide the capability to define and automate workflows that involve
any documentation associated with the Client/Patient record to include: Routing rules,
HD
Due dates for completion and/or approvals, and Notifications and alerts regarding past
or future due dates.
1.10.2.36 The system shall provide an audit trail of users accessing and using electronic and
HD
physical Client/Patient records.
1.10.2.37 The system shall provide a means to track client/patient authorization by each specific
D
type of Release of Information.
1.10.2.38 The system shall maintain the user name, location, date, and time, based on HIPAA
privacy and security requirements, when a user duplicates any part of the electronic or HD
physical Client/Patient record for any media.
1.10.2.39 The system shall generate and send notifications to users of any limited information
HD
disclosure request or requirement as specified in the electronic Client/Patient record.
1.10.2.40 The system shall generate a notification to users attempting to use sections of
HD
Client/Patient records currently open for update by another user.
1.10.2.41 The system shall generate reminders to appropriate County staff regarding completion
and/or resolution of documentation in the Client/Patient record to meet compliance HD
requirements.
1.10.3 Abstracting Data: Automatically extracting a subset of data already in the record for Medicare, Medicaid, vital records, etc. reporting.
No system requirements were identified specific to this process.
1.10.4 Analyzing Charts for Deficiencies and Delinquencies: Reviewing the completeness of a client's chart and following up with service providers to ensure the timely

Appendix C - Functional Requirements (PS-1034) Page 52 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
No system requirements were identified specific to this process.
1.10.5 Record Completiont: Monitoring unsigned/co-signed reports, results, etc.
1.10.5.1 The system shall capture and maintain electronic signatures for providers/staff and HD
clients.
1.10.5.2 The system shall support the use of electronic signatures (i.e., non-repudiation) for
HD
final, legal approval.
1.10.5.3 The system shall support tasks and work flow associated with supervision of interns
HD
(e.g., required approval or co-signature of an intern's note before it can be billed).
1.10.6 Managing Release of Informationt: Ensuring clients, staff, and external sources have access to or receive needed personal health information (PHI) in a manner
consistent with HIPAA and other pertinent business requirements.
1.10.6.1 The system shall generate, maintain, and monitor various Release of Information forms. HD
1.10.6.2 The system shall maintain and store signed release of information forms. HD
1.10.6.3 The system shall enable users to select standard release forms using a pull-down menu. HD
1.10.6.4 The system shall capture the following disclosure information: Date of disclosure, To
Whom the information was disclosed, Reason for disclosure, Information disclosed, HD
and Person releasing the information.
1.10.6.5 The system shall track all disclosures of information. HD
1.10.6.6 The system shall provide the capability to de-identify/redact data reported and released
HD
according to County Privacy Policy.
1.10.6.7 The system shall provide the capability to define, document, manage, and track in the
electronic record:
- All requests for Release of Information
D
- Authorizations
- Revocations
- Consents
1.10.6.8 The system shall track the status of each Request for Information as received, pending,
D
denied, or completed.
1.10.6.9 The system shall mark all released information with the appropriate County standard
D
disclosure clause for a specific type of release of information.
1.10.6.10 The system shall mark all released information &quot;as not available for further
D
disclosure&quot; unless client/patient authorization is provided.

Appendix C - Functional Requirements (PS-1034) Page 53 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
1.10.6.11 The system shall support the implementation of specific rules regarding Release of
Information policies, procedures, and protocols to include: the creation of forms
D
appropriate to the type of Request, defining user roles who are permitted to release
information, and defining necessary correspondence related to a type of Release.
1.10.6.12 The system shall generate an invoice for any associated fees triggered by a specific
D
type of Request for Information.
1.10.6.13 The system shall generate any necessary correspondence related to a Release of
D
Information.
1.10.6.14 The system shall provide an audit trail (i.e., disclosure log) on any information related
D
to the release or disclosure of client/patient information.
1.10.7 Managing Consents and Authorizations: Ensuring accurate, current, and necessary consents and authorizations are completed, stored, and accessible to providers;
includes tracking disclosures, directives, etc.
1.10.7.1 The system shall generate, maintain, and monitor various Consent and Authorization
HD
forms.
1.10.7.2 The system shall generate, maintain, and monitor various Advanced Directives,
HD
Durable Power of Attorney forms, etc.
1.10.7.3 The system shall maintain and store signed consent and authorization forms, Advanced
HD
Directives, DPAs, etc.
1.10.7.4 The system shall capture and retain current and historical dosage range for inpatient
HD
medications directly on the consent or authorization form.
1.10.8 Transcribing: Includes editing information created by natural language processing (NLP).
1.10.8.1 The system shall support speech/voice recognition, dictation, transcription, and text-to-
D
speech.
1.10.8.2 The system shall support the electronic export/import of dictation/transcription of all D
notes.
1.10.9 Managing External Documents: Document and image management, including receiving, scanning, storing, and indexing documents received from external sources
1.10.9.1 The system shall have the capability to capture/import and store an external file,
associate it (i..e, image, document, audio) with any record or its associated metadata in
HD
the system (i.e., Client/Patient record), and manage (i.e., inedex. print, annotate,) the
file in an compatible Agency-standard format.

Appendix C - Functional Requirements (PS-1034) Page 54 of 110
Functional Requirements
1.10 Health Record Management

Requirement How
Prior. Avail. Description
Met
1.10.9.2 The system shall support the display, management, and annotation of standard image
HD
formats (e.g., TIFF, JPEG, GIF, BIIF, BMP, PNG)
1.10.9.3 The system shall support the capability for voice to text on voice files and to manage
D
the output together with the audio clip.
1.10.9.4 The system shall assign a unique identifier to each image (or other file) being
D
referenced by the system.
1.10.9.5 The system shall have the capability for performing optical character recognition
(OCR) on image in County standard formats and to manage the resulting output D
together with the original image.
1.10.9.6 The system shall be extensible to incorporate the display and management of other
D
electronic file formats described by a formal standard or vendor specification.
1.10.9.7 The system shall provide the capability for an authorized user the ability to annotate a
D
file electronically and save the annotation with the file.

Appendix C - Functional Requirements (PS-1034) Page 55 of 110
Functional Requirements
1.14 Education Counseling

Requirement How
Prior. Avail. Description
Met
1.14 Education / Counseling / Therapy / Groups / Activities: Education, counseling, therapy, and medication are common approaches to treatment of behavioral health
problems. The processes by which these services are provided are core components of a client's treatment and are provided in accordance with the treatment plan.
Documentation of units of service is required by funding sources and payers.
1.14.1 Education: Occurring in individual or group (including family) settings, providing rehabilitation interventions to assist client in gaining skills. Includes delivering
didactic education classes (DA/S), disseminating client/patient education material, and providing prevention activities aimed at educating the community.
1.14.1.1 The system shall maintain a record of current curriculum components for educational
D
activities.
1.14.2 Counseling/Therapy: Providing individual, group, family, or collateral therapy. .
1.14.2.1 The system shall alert authorized users when client/therapist ratio exceeds user-defined
HD
program standards.
1.14.2.2 When services are entered for a group, all group members are displayed for rapid data
HD
entry.
1.14.2.3 The system shall notify the clinician when a client's treatment or program requirements
HD
are not being or have not been met.
1.14.2.4 The system shall capture therapist and co-therapist time. HD
1.14.2.5 The system shall automatically perform error checks to verify accuracy of data entered
HD
and reduce therapist billing errors.
1.14.3 Medication: Prescribing medication to reduce/address mental health symptoms or facilitate detoxification, using a Psycho-pharmaceutical approach to client change.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 56 of 110
Functional Requirements
1.16 Notes Documentation

Requirement How
Prior. Avail. Description
Met
1.16 Notes / Documentation: Notes and documentation refers to entering information into a client's record. Notes and documentation are required to record service, treatment,
or care-related comments and findings that may be related to assessments, evaluations, history, physicals, lab results, reaction to medications, special diets, etc. In addition to
individualized notes, notes and documentation for group sessions are also prepared.
1.16.1 Determining Format and Content of Note: Determining note and documentation format, content, and document workflow based on program and payer guidelines
and requirements. Includes an interface with 26.0 Coding to ensure proper note completion.
1.16.1.1 The system shall support multiple note types needed to document the various activities
HD
required to manage client/patient placement cases.
1.16.1.2 The system shall permit user customization of progress note types, formats, and content
HD
according to the requirements of each program.
1.16.1.3 The system shall provide the ability to modify the case notes template by the type of
HD
service.
1.16.1.4 The system shall prompt users to enter notes within a user-defined time period from the
HD
date of service
1.16.1.5 The system shall support progress notes for individuals and for groups. HD
1.16.1.6 The system shall support supplemental notes. HD
1.16.1.7 The system shall integrate hand-written notes into the record (e.g., able to scan and
HD
apply intelligent character recognition).
1.16.1.8 The system shall include standard word processing functions with spell check to
HD
compose notes.
1.16.1.9 The system shall support field workers sending real-time data or uploading data to
HD
central system daily when computer is docked (Note: Does not denote wireless)
1.16.1.10 The system shall have Free-text fields that accommodate lengthy entries. HD
1.16.2 Completing Note/ Documentation: Ensuring that providers meet the requirements for providing services and document services provided according to program/payer
1.16.2.1 requirements. provide the capability for authorized users to enter electronic progress
The system shall
D
notes and recommendations.
1.16.2.2 The system shall restrict user access to sections of a progress note according to user D
1.16.2.3 role.system shall permit clinicians to voew the current treatment plan while writing a
The
HD
progress note.
1.16.2.4 The system shall incorporate the treatment plan into the inpatient shift summary. HD
1.16.2.5 The system shall permit access to both inpatient and outpatient notes within a single
HD
client record simultaneously.

Appendix C - Functional Requirements (PS-1034) Page 57 of 110
Functional Requirements
1.16 Notes Documentation

Requirement How
Prior. Avail. Description
Met
1.16.2.6 The system shall support importing inpatient unit (PHF) notes into outpatient (MHS)
D
notes.
1.16.2.7 The system shall link progress notes to the treatment plan as required by regulatory
HD
guidelines.
1.16.2.8 The system shall have the option to prohibit clinicians from entering notes without an
D
approved treatment plan.
1.16.2.9 The system shall flag the need to complete the progress note for individual
HD
participation in a group session.
1.16.2.10 The system shall automatically populate individual notes with Group note information
HD
(that details the group content / structure) for each individual in the group.
1.16.2.11 The system shall permit the annotation of an individual group note to describe how
HD
each person responded to that content.
1.16.2.12 The system shall enable Group notes to be set up so that the entire group can be
opened at one time, ensure consistent documentation across the group, and make sure HD
that individualized information can be entered.
1.16.2.13 The system shall support linking a client's notes to other information, either maintained
in the system or in other County systems, the linkage related to the client's family as D
defined by program requirements.
1.16.2.14 Notes are automatically populated with information previously captured (e.g., patient
HD
demographics, RU, time, diagnosis, and mental status exam).
1.16.2.15 The medication entered in the &quot;prescribe today&quot; field on the progress note
HD
automatically populates the prescription, medication consent, and medication log.
1.16.2.16 The system shall provide the capability for a progress note to be organized by D
discipline. Note/ Documentation Status: Tracking applicable notes/documentation for clinical appropriateness, timelines, and overall system of care.
1.16.3 Tracking
1.16.3.1 The system shall provide the capability for authorized users to view and print progress
D
notes in chronological order.
1.16.3.2 The system shall generate notifications to designated recipients when time-specific
progress notes/documentation is required according to documentation rules established D
for progress notes.
1.16.3.3 The system shall generate a notification to the pharmacist, physician and nurse when
D
the monthly pharmacy drug regiment review is due.

Appendix C - Functional Requirements (PS-1034) Page 58 of 110
Functional Requirements
1.16 Notes Documentation

Requirement How
Prior. Avail. Description
Met
1.16.3.4 The system shall provide the capability for authorized users to maintain daily and
D
weekly discharge information.
1.16.3.5 The system shall automatically generate a service transaction which is linked to an
HD
approved progress note.
1.16.3.6 The system shall not forward a service transaction to the billing until the progress note
HD
is final (i.e., not pending).
1.16.3.7 The system shall be configurable so the automatic generation of the service transaction
may be disabled and the process completed manually. This may be required for HD
particular organizational providers or clinical staff.
1.16.3.8 The system shall immediately validate all services entered into the system. HD
1.16.3.9 The system shall automatically validate that services rendered were performed by
HD
appropriately credentialed staff.
1.16.3.10 The system shall maintain the note history by program, site, and admission episode. HD
1.16.3.11 The system shall integrate attendance records for scheduled sessions with client notes. HD

Appendix C - Functional Requirements (PS-1034) Page 59 of 110
Functional Requirements
1.22 Case Management

Requirement How
Prior. Avail. Description
Met
1.22 Case Management: Case Management is the process of linking and monitoring the appropriateness of treatment or ancillary services to an individual client throughout the
client's episode of care. Services may include housing, dental care referral, etc. Case management often involves referral to providers outside of the Health Agency's purview
(e.g., to IMDs, state hospitals, after care).
1.22.1 Initial/ Ongoing Development of Case Management Plan: The process of developing individual client treatment or service plans based on the client's unique needs.
Revising and updating the plan as needed, as the case progresses and various steps and activities are performed, and as new needs or issues arise.
No system requirements were identified specific to this process.
1.22.2 Case Management and Monitoring: The process of actively managing a client's case according to the individual client treatment or service plan, including making
referrals as appropriate. Coordinating and monitoring all service delivery in compliance with the plan to improve outcomes, quality of care, and cost-effectiveness.
1.22.2.1 The system shall track clients/patients receiving services from community based
organizations, including but not limited to capturing Service accepted, Service denied, HD
Active/Inactive, and Disposition.
1.22.2.2 The system shall permit Physicians to have access to case manager's section of the
HD
record.
1.22.3 Documentation: Documenting the activities, outcomes, results, issues, etc. of activities performed.
1.22.3.1 The system shall allow for flexible presentation of information. HD

Appendix C - Functional Requirements (PS-1034) Page 60 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Functional Category Title Section # Description
CPOE 17.0 Orders/Results
19.0 Laboratory - Drug Testing
20.0 Prescriptions Medication
21.0 Dietary

Appendix C - Functional Requirements (PS-1034) Page 61 of 110
Functional Requirements
1.17 Orders Results

Requirement How
Prior. Avail. Description
Met
1.17 Orders / Results: Orders include the issuing and documentation of a physician's request for lab tests, medications, diagnostic exams, special diets, various treatments,
services etc. Results include receiving and retaining the outcome of tests that were ordered and performed. After determining appropriate tests and services (e.g., medical, drug,
and diagnostic) based on assessment, clinician orders tests and services. Tests are performed at facilities, in-house or other divisions within HA. Orders are currently stored in
database and paper file.
1.17.1 Determining Format and Content of Note: Determining note and documentation format, content, and document workflow based on program and payer guidelines
and requirements. Includes an interface with 26.0 Coding to ensure proper note completion.
1.17.1.1 The system shall support a protocol-driven order process that is based on best clinical
D
practice.
1.17.1.2 The system shall support the design and implementation of standard workflow
processes for order entry that consist of one or more steps, establishes the time periods
for each step in the workflow process, defines approval process (including the specific D
parameters needed for approvals and the approving user/role needed at each specific
step), and enforces the approval process through the use of electronic signature.
1.17.1.3 The system shall associate the ordering provider and the attending physician with a
D
single order.
1.17.1.4 The system shall provide the capability for additional, multiple providers and/or
D
clinicians to be associated with a single order, such as members of the client/patient's
The team.
1.17.1.5 care system shall provide the capability for an authorized user to define a series of
D
orders or recurring orders to be entered once with multiple dates in the future.
1.17.1.6 The system shall support best clinical practice/protocol-driven order sets (e.g., bundled
D
lab orders per MD-ordered withdrawal protocol).
1.17.1.7 The system shall provide the capability to create order sets, save standard orders sets
D
for re-use, update order sets, and tag order sets as inactive or not in use.
1.17.1.8 The system shall support standing orders. HD
1.17.1.9 The system shall allow an authorized user to mark an order as 'no charge' during entry
D
or update.
1.17.1.10 The system shall provide a user interface for an authorized user to enter an order
HD
online, via voice recognition, and via transcription of a hand-written or verbal order.
1.17.1.11 The system shall route the order to the appropriate recipient(s) as defined by the
HD
clinical workflow.

Appendix C - Functional Requirements (PS-1034) Page 62 of 110
Functional Requirements
1.17 Orders Results

Requirement How
Prior. Avail. Description
Met
1.17.1.12 The system shall transmit the order to a designated recipient using routing methods
D
internal to the system (i.e., workflow), E-mail, and FAX
1.17.1.13 The system shall transmit the order to external providers by: FAX, electronic interface
with other systems (e.g., HL7), email, on-line access by external provider (e.g., D/AS HD
results to court).
1.17.1.14 The system shall provide the capability for a user to enter directly into the system (i.e.,
Client/Patient record) at the point of care/service the treatment, services, and/or and D
supplies being provided.
1.17.1.15 The system shall automatically generate all appropriate forms (e.g., consent form) and
D
navigate to appropriate screens according to the order or protocol.
1.17.1.16 The system shall flag contraindications when a medication is ordered, including
D
allergies, food-drug, or drug-drug interactions.
1.17.1.17 The system shall generate an alert when a medication ordered exceeds the dosage range.
HD
1.17.1.18 The system shall generate a medication consent form when specific medications are
ordered by an inpatient provider (e.g., Benzodiazepines, hypnotics, narcotics, HD
neuroleptics, mood stabilizers, and other medications that alter one's sensorium).
1.17.1.19 The system shall generate a medication consent form when any medication is initially
HD
ordered.
1.17.1.20 The system shall permit inpatient providers to adjust medications without generating or
HD
requiring a new consent or authorization form.
1.17.1.21 The system shall generate a medication consent form when an outpatient mental health
HD
service provider changes the dosage range for a medication already ordered.
1.17.1.22 The system shall support medication-specific, protocol-based triggers for inpatient lab
D
orders and clinic-based lab work.
1.17.1.23 The system shall provide alerts relative to time limits or expirations of orders (e.g.,
D
medications, lab results).
1.17.1.24 The system shall provide an electronic MAR that is automatically updated by orders,
HD
and is integrated with the record.
1.17.1.25 The system shall automatically transfer the order to the MAR and to the pharmacy
HD
system.

Appendix C - Functional Requirements (PS-1034) Page 63 of 110
Functional Requirements
1.17 Orders Results

Requirement How
Prior. Avail. Description
Met
1.17.1.26 The system shall provide a universal medication profile for a client that ensures
medication orders, medications dispensed, and medication administration records HD
adhere to protocols associated with the medication profile.
1.17.1.27 The system shall provide a universal medication profile for a client that ensures
HD
standing orders and order sets for tests (e.g., lab) are appropriate.
1.17.1.28 The system shall match a client's drug test profile to a client's drug of choice to ensure
that appropriate tests are ordered based on medications reported by client (e.g., if client D
is on Vicodin, make sure that the test ordered from Redwood is appropriate).
1.17.1.29 The system shall provide alerts and notifications based on due dates (e.g., labs are
overdue) and protocols (e.g., medication protocols require recurring lab, seclusion and HD
restraint protocols).
1.17.2 Receiving Results: Receiving test results for tests done in-house (e.g., dipstick), receiving results for tests done by outside lab facilities or other divisions within the
Health Agency via fax or e-mail notifications. Results are stored in database and paper file.
1.17.2.1 The system shall link results to the original order. HD
1.17.2.2 The system shall generate a notification to authorized users when new results from any D
1.17.2.3 The system shall alert the labs, or follow-up services are received into the system.
clinical assessments, tests,authorized user (e.g., sponsor, original provider) that results
D
have been received or are overdue.
1.17.2.4 The system shall automatically notify appropriate staff that a result has been received
D
for which an interpretation is required.
1.17.2.5 The system shall flag abnormal values that fall outside of user-defined normal levels,
HD
thresholds, or ranges.
1.17.2.6 The system shall accept and capture results into the electronic record using the
HD
following methods: on-line entry, inbound FAX, scanned documents.
1.17.2.7 The system shall accept order results into the Client/Patients Electronic Health Record
either through on-line (screen) entry by an authorized user and/or import of results D
captured in system-accepted formats.
1.17.2.8 The system shall provide the capability for an authorized user to indicate in the
D
client/patient's EHR the location of results on physical media or paper.
1.17.2.9 The system shall support the use of an electronic signature as a means for final
D
approval of laboratory test results, either single or in batch.

Appendix C - Functional Requirements (PS-1034) Page 64 of 110
Functional Requirements
1.19 Laboratory Services
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.19 Laboratory Services: The key function of laboratory services is to furnish providers with accurate lab test results on a timely basis. The Agency performs limited testing
in-house and outsources other lab services. Both MHS and DA/S use outside labs for these services (e.g., the PHF contracts with French Hospital and DA/S contracts with
Redwood Toxicology for drug test results).
1.19.1 Placing People in Testing Groups: Randomly assigning individuals to testing groups that specify dates, times, frequency, and location of test(s) to be performed.
1.19.1.1 The system shall create rosters of people testing on a user-defined date or date range,
HD
gender, program and/or treatment site.
1.19.1.2 The system shall reference all specimens by Client/Patient identifier and by batch in
D
which specimen was collected.
1.19.2 Generating Labels: Entering client information onto labels that will be printed and affixed to sample container for the purpose of ensuring valid correlation of test
result to client sample. Includes automatically assigning accession numbers.
1.19.2.1 The system shall automatically generate pre-defined specimen labels from a client HD
1.19.2.2 roster.
The system shall generate test labels for tests that occur off-schedule (unscheduled) or
D
on an ad-hoc basis.
1.19.2.3 The system shall automatically print user-defined aliquot collection labels, ensuring
that test names are printed on labels and specimen requirements on labels or adjacent D
label stock.
1.19.2.4 The system shall provide the capability for an authorized user to print bar-coded
D
collection labels at a designated location (e.g., Client/Patient ward/location).
1.19.2.5 The system shall reprint collection lists and associated collection labels on demand. D
1.19.2.6 The system shall support the creation of collection lists automatically or on-demand
D
according to user-specified date/time, route, or physical location.
1.19.3 Performing Lab Test: Based on established protocols, certain tests are performed in-house (e.g., dip sticks) whereas other tests are outsourced.
1.19.3.1 The system shall support both mobile and fixed bar-code wand scanners for logging a
D
specimen into the system and tracking it.
1.19.4 Tracking Test Status: Tracking and monitoring the status of lab tests that have been sent out.
1.19.4.1 The system shall permit an authorized user to manually log a specimen into the system. D
1.19.4.2 The system shall automatically generate Accession numbers for tracking specimens. HD
1.19.4.3 The system shall support the capability for an authorized user to query Client/Patient
laboratory results and orders by Client/Patient name, Client/Patient identifier, Lab D
billing number

Appendix C - Functional Requirements (PS-1034) Page 65 of 110
Functional Requirements
1.19 Laboratory Services
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.19.4.4 The system shall support the capture and reporting of data for STAT and other priority
D
order audits
1.19.4.5 The system shall support the use of bar-codes for the logging in and tracking of
D
specimens by an authorized user.
1.19.5 Receiving Results: Electronic downloading of test results (e.g., from Redwood Toxicology in Santa Rosa, CA).
1.19.5.1 The system shall receive test results via the web. HD
1.19.5.2 The system shall receive and store electronic results securely. HD
1.19.5.3 The system shall generate alerts when laboratory results are received electronically. HD
1.19.5.4 The system shall automatically notify physician when lab result has been received. HD
1.19.5.5 The system shall automatically apply pre-defined text to the documentation of
laboratory results based on user-defined parameters or the contents of the test HD

1.19.5.6 dictionary. shall provide the capability for the graphical display of laboratory results
The system
according to user-defined time periods, value ranges, and number of specified result D

1.19.5.7 sets. system shall support reference ranges, including critical high and critical low
The
D
values by an authorized user.
1.19.6 Recording and Storing Test Results: Recording and storing lab results in the system.
1.19.6.1 The system shall have the ability to manually enter lab results. HD
1.19.6.2 The system shall have the ability to electronically notify staff that lab results are posted. D
1.19.6.3 The system shall automatically record test results in the client chart. HD
1.19.6.4 The system shall provide the capability for an authorized user to compare current and
D
historical lab results by test or profile.
1.19.6.5 The system shall permit Amendments to ranges D
1.19.6.6 The system shall track historical ranges (by date and type of laboratory test) D
1.19.7 Capturing Order Request: For inpatient PHF, laboratory order information is captured and documented via telephone, fax, or online (Internet, intranet). An
interface between the pharmacy and laboratory functions is required to allow restricting issuing prescriptions until laboratory results are obtained.
1.19.7.1 The system shall capture orders for lab tests electronically. HD
1.19.7.2 The system should generate lab slips. HD
1.19.7.3 The system shall integrate laboratory order entry as part of electronic order entry. HD
1.19.7.4 The system shall permit authorized users to add procedures and specimens to a lab HD
1.19.7.5 order.
The system shall permit authorized users to enter laboratory orders for Past date,
HD
Current date, Future dates
1.19.8 Transmitting Order: Transmitting the order to the lab that will fulfill the order.

Appendix C - Functional Requirements (PS-1034) Page 66 of 110
Functional Requirements
1.19 Laboratory Services
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.19.8.1 The system shall electronically transmit a HIPAA compliant secure order to an internal
HD
or external laboratory.
1.19.8.2 The system shall provide the ability to print a HIPAA compliant secure order to an
HD
internal or external laboratory.
1.19.9 Generating Billing/Payment: Billing or payment information is processed.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 67 of 110
Functional Requirements
1.20 Pharmacy Medication
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.20 Pharmaceutical / Medication Management Services: Pharmacy services represents the process of accepting and fulfilling a prescription order, performing drug
utilization reviews (DUR), billing for the pharmaceutical service, and maintaining a record of the transaction. The pharmacy process may include the acquisition, distribution,
and control of all pharmaceutical products, including medications, injectables, and supplies. The process may also include educating clients and providers about drugs or advise
providers on drug selection. Neither MHS nor DA/S operates a pharmacy; MHS and DA/S outsource the fulfillment of medication orders to Community Health Centers (CHC).
CHC will continue filling PHF Pharmacy orders. The system should interface with the Med-Dispense unit located in the PHF.
1.20.1 Capturing Order Request: Pharmacy order or prescription information is captured verbally or via telephone, fax, or online (Internet, intranet) and documented. The
system will have a GUI interface that will encourage the prescribing clinician to enter the prescription directly into the system. Physician orders medications by
phone, fax, or script. Checks JV220 status and complete form(s) as needed.

1.20.1.1 The system shall support entry of original pharmacy orders directly into the system. HD
1.20.1.2 The system shall permit the update or edit of all pertinent fields of a pharmacy order
D
(e.g. select another drug).
1.20.1.3 The system shall support Renewal of an order (e.g. stop-dated orders, transfer orders) D
1.20.1.4 The system shall support Cancellation or Discontinuation of an order D
1.20.1.5 The system shall reject invalid/inappropriate orders and route information to
D
appropriate users to resolve.
1.20.1.6 The system shall support order "Holds" for specified term with automatic resumption
D
and open-ended terms.
1.20.1.7 The system shall support ePrescribing. D
1.20.1.8 The system shall electronically transmit a HIPAA-compliant secure prescription to
HD
internal and external pharmacies.
1.20.1.9 The system shall provide the ability to print a prescription. HD
1.20.1.10 The system shall make treatment plans and progress notes accessible and viewable
HD
during the prescription-writing process.
1.20.1.11 The system shall support wireless prescription device solutions. HD
1.20.2 Dispensing and Administration of Orders: Based on formulary or special order protocols, pharmacy prepares or dispenses medications as ordered (internally or
outsourced). MHS outpatient dispenses samples and both MHS inpatient and outpatient administer injectables and other medications. DA/S administers Detox kits
that are dispensed by CHC.
1.20.2.1 The system shall support review of an order by pharmacist. D
1.20.2.2 The system shall support verification and approval of a pharmacy order as entered. D
1.20.2.3 The system shall support online drug interaction checks for drug/drug interactions,
D
drug/lab, drug/food, and drug/allergy.
1.20.2.4 The system shall provide alerts for drug-drug, food-drug, drug-allergy interactions, etc. HD

Appendix C - Functional Requirements (PS-1034) Page 68 of 110
Functional Requirements
1.20 Pharmacy Medication
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.20.2.5 The system shall support ordering injectables. HD
1.20.2.6 The system shall comply with Federal Medicaid Guidelines and State regulations for
D
tamper-proof prescriptions.
1.20.2.7 The system shall print prescription on tamper-proof paper without having to change the
D
paper tray.
1.20.2.8 The system shall track medications received, dispensed, returned, etc. HD
1.20.2.9 The system shall provide notification of required follow-up activities for the
HD
administration of emergency medications, PRNs, and STATs within user-defined
1.20.2.10 timeframes. shall generate a single medication profile for each client that is viewable on
The system
HD
a single screen
1.20.3 Documentation: Documenting PHF pharmacy information, such as MD Note, transcribed to medication administration record (MAR), medical note, medical log,
1.20.3.1 medical request generate and maintain an electronic medication log.
The system shallslip. HD
1.20.3.2 The system shall support medication dispensing through an electronic Medication HD
1.20.3.3 Administration Record (MAR) that tracks user-defined information for all medications
The system shall generate medication consent forms, capture client/patient signatures D
1.20.3.4 electronically, and retainthat pharmacy management functions are fully integrated with
The system shall ensure signed consent forms. D
1.20.3.5 The system shall have the ability Administration Record (eMAR) so that all orders,
the system electronic Medication to document and report various clinical monitors, e.g. D
1.20.3.6 The system shall support the ability Error, Non-Formulary Drug request.
Adverse Drug Reaction, Medicationto add patient specific comments (e.g., reactions to D
1.20.4 Tracking Order identify the user and monitoring the status of
medications) and Status: Trackingwho generated the comment. the order.
1.20.4.1 The system shall automatically notify staff when CHC medication is ready for pick up. D
1.20.4.2 The system shall automatically notify staff after the patient has picked up a medication. D
1.20.4.3 The system shall provide the capability for an authorized user to enter information
regarding the fulfillment of a pharmacy order (whether through dispensing or D
administration) directly into a client/patient's medical record.
1.20.4.4 The system shall provide the capability for an authorized user to access and view
pharmacy orders over time for a user-defined Client/Patient or population to analyze D
drug usage and dispensing/administration patterns for that Client/Patient or population.
1.20.4.5 The system shall support pharmacy order renewals without re-entering them into the
system, including conversion of existing inpatient orders to outpatient (pass or D
discharge) orders and conversion of existing outpatient orders to inpatient/admitting
1.20.4.6 orders.
The system shall generate a notification to an authorized user when pharmaceutical
D
orders are entered into the system.

Appendix C - Functional Requirements (PS-1034) Page 69 of 110
Functional Requirements
1.20 Pharmacy Medication
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.20.5 Medication Management Services: Performing or obtaining necessary assessments of the client/patient's health status; Obtaining authorizations, including TAR;
Formulating a medication treatment plan; Selecting, initiating, modifying, or administering medication therapy; Dispensing samples and related documentation;
Administering injections and medications (including detox kits ordered through CHC) and related documentation; Monitoring and evaluating the client/patient's
response to therapy, including safety and effectiveness; Performing a comprehensive medication review to identify, resolve, and prevent medication-related problems,
including adverse drug events; Documenting the care delivered (including medication log, MAR, patient reaction to medications); and communicating essential
information to the client/patient's other primary care providers; Providing verbal education and training designed to enhance patient understanding and appropriate use
of his/her medications. Providing information, support services, and resources designed to enhance patient adherence with his/her therapeutic regimens (including
providing patient education material); Coordinating and integrating medication therapy management services within the broader health care management services
1.20.5.1 The system shall the patient.
being provided toprompt the doctor to obtain a medication consent in user-defined
HD
situations.
1.20.5.2 The system shall support the Treatment Authorization Request (TAR) for medication
HD
requests.
1.20.5.3 The system will maintain a single medication profile for each client that includes
information about medications prescribed by the County, those being taken but
HD
prescribed by another provider, drug allergies, and other related and relevant
information for client protections.
1.20.5.4 The system shall link directly to client profiles in the County pharmacy and other retail
D
pharmacies with whom HA has a business relationship.
1.20.5.5 The system shall automatically update the medication log based on physician orders. HD
1.20.5.6 The system shall provide an electronic record of client sign-off on Medication Consent
HD
Forms.
1.20.5.7 The system shall contain or access the JV220(A) Form for physicians seeking authority
from the court to prescribe psychotropic medications to wards of the court who are HD
placed outside of their home.
1.20.5.8 The system shall support the PHF's REISE process (3 forms to Court for approval) for
HD
medications administered to juveniles.
1.20.5.9 The system shall provide an alert to the physician if a client reports side effects
HD
attributable to prescribed medications.
1.20.5.10 The system shall be capable of interfacing with external drug information sources. HD
1.20.5.11 The system shall require that a physician document the reason a medication was
HD
discontinued.

Appendix C - Functional Requirements (PS-1034) Page 70 of 110
Functional Requirements
1.20 Pharmacy Medication
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.20.5.12 The system shall retain information about medications that were tried and considered
HD
ineffective, and medications that were discontinued for other reasons.
1.20.5.13 The system shall maintain a history of administered injection sites, including body site
HD
and when administered.
1.20.5.14 The system shall have online drug interaction, duplication of therapy, allergy alerts that
are provided to an authorized user at the points of order entry and validation of the D

1.20.5.15 order.
The system shall produce drug ID description on label as required by regulation and
D
the ability to edit drug ID descriptions at point of order entry for each fill/refill.
1.20.5.16 The system shall have the capability to establish and meet time-specific reporting
requirements as established by regulation and accreditation standards including D
CURES (controlled substance utilization Review and evaluation system).
1.20.5.17 The system shall have the ability to perform medication dose calculations. D
1.20.5.18 The system shall generate alerts to designated recipients (e.g., client/patient's care team
and physician) of pertinent medication clinical information. D

1.20.5.19 The system shall permit an authorized member of the client/patient's care team to
access a common client/patient medication history in order to deliver appropriate D

1.20.5.20 and/or coordinated pharmaceutical care. to approve an order as entered or select
The system shall permit CHC pharmacists
another drug as needed. D

1.20.5.21 The system shall support control of Injectible medications. HD
1.20.6 Generating Billing/Payment: Processing billing or payment information on a timely basis.
No system requirements were identified specific to this process.
1.20.7 Maintaining Formulary: Maintaining the inpatient formulary for the Psychiatric Health Facility (PHF).
1.20.7.1 The system shall capture and store data on medication types, dosages, and County rates
HD
per dosage.
1.20.7.2 The system shall maintain and update a locally-defined formulary and display "first-
HD
choice" drugs.
1.20.7.3 The system shall provide the capability to manage the primary County drug formulary
D
and support live updates of on-line formularies, pricing, and drug alternatives.
1.20.7.4 The system shall support Drug Formulary Management, with live updates to
formularies and drug alternatives available via the solution provider or another service D
(e.g., First Data Bank).

Appendix C - Functional Requirements (PS-1034) Page 71 of 110
Functional Requirements
1.20 Pharmacy Medication
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.20.7.5 The system shall permit an authorized user to submit an electronic Non-Formulary
Request in accordance with County policy for same. The request shall be viewable and D
editable (edit history viewable) by other authorized users.
1.20.8 Managing Inventory : Maintaining and controlling the inventory of medications (drug supplies). Maintaining the PHF's MAR, drug samples, lot lists, and ensuring
1.20.8.1 The system shall manage inventory for samples drugs, including tracking and providing
HD
alerts for those medications that are reaching or have reached expiration dates.
1.20.8.2 The system shall use bar code technology to manage inventory of drug samples. D
1.20.8.3 The system shall maintain a log and perpetual inventory of drug samples. D
1.20.8.4 The system shall provide the capability for pharmacy inventory management that is
D
fully integrated with the pharmacy management functionality.
1.20.8.5 The system shall maintain pharmacy inventory control across multiple County D
1.20.8.6 The system must be able to track sub-inventories for controlled drugs. D
1.20.8.7 The system shall support sub-inventory control including controlled substances (e.g.,
narcotic drug dispensing (CII-V), ward stock distribution and dispensing) and generate HD
various reports in order to manage and document these inventories.
1.20.9 Educating and Performing Research: Providing educational materials and researching drugs.
1.20.9.1 The system shall have the ability to generate medication drug profiles. HD
1.20.9.2 The system shall have the ability to generate drug monographs. D
1.20.9.3 The system shall be capable of printing out educational information on medications
HD
being administered or dispensed.

Appendix C - Functional Requirements (PS-1034) Page 72 of 110
Functional Requirements
1.21 Dietary
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.21 Dietary: Dietary is the provision of snacks and meals to clients and supports the therapeutic monitoring of a client's dietary intake and output. Both the PHF and DA/S
serve meals and snacks to clients. Dietary includes setting aside food for PHF patients in case of disaster. Dietary functions are out-sourced.
1.21.1 The system shall support dietary functions on the PHF. HD
1.21.2 The system shall support inventory management of outpatient meals and snacks across
HD
multiple locations.
1.21.3 The system shall permit an authorized user to maintain food supply inventory by HD
1.21.4 location. shall capture and store information on client food allergies.
The system HD
1.21.5 The system shall track dietary requirements for each patient by unit, room and bed and
HD
create dietary orders for the kitchen.
1.21.6 The system shall capture and track dietary orders for outpatient meals and snacks. HD
1.21.7 The system shall support the delivery of medical nutrition services to a Client/Patient,
including tracking weight, maintaining nutrition assessments and information, and D
maintaining calorie count information.
1.21.8 The system shall track a Physician Dietary Order and calculate the calorie intake
D
associated with individual meals and/or total daily intake.

Appendix C - Functional Requirements (PS-1034) Page 73 of 110
Functional Requirements
1.9 Bed Management
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.9 Bed Management: The bed management function allows the Health Agency to track the availability of beds in Agency-owned or -managed client accommodations by type
of facility (e.g., 24 hour care facility, apartments) and to generate rosters by facility that may be used to support resource management and payer requirements.
1.9.1 Monitoring/Managing Bed Availability: Maintaining accurate and up-to-date status of occupied beds relative to total available bed capacity. Maintains information
for inpatient PHF and all other Agency owned or managed beds in the community.
1.9.1.1 The system shall alert staff when the PHF's 16-bed capacity is nearing maximum in
HD
order to avoid citation (e.g. alert when 14 of 16-beds are full)
1.9.1.2 The system shall provide a consolidated history of a client/patient's movement
D
throughout his or her stay at the PHF, including reasons for movement.
1.9.2 Assigning Patient to an Inpatient Bed and/or Room (PHF)/Changing Bed Assignment: Noting which bed and/or room an individual patient will be placed for the
duration of their inpatient stay. Takes into consideration availability of beds, the client's behavior, and client's age, and sex. Noting changes in bed and/or room
placements that may occur during an inpatient stay.
No system requirements were identified specific to this process.
1.9.3 Managing Placements: Based on assessment, client's level of care is determined. Client may be placed at a number of Agency owned or managed beds in facilities
throughout the County representing various levels of care (e.g., Group Homes and IMD).
1.9.3.1 The system shall track entry and exit dates of each housing placement for each client. HD
1.9.3.2 The system shall track what type of housing is being used by the client on each housing
HD
placement (standard user-defined housing classifications).
1.9.3.3 The system shall track total length of stay (number of days occupied), counting day
HD
entering placement, but not counting day of discharge.
1.9.3.4 The system shall track and report benchmarks of housing placement (e.g., at the 30-day
D
mark, 6-month mark and 12-month mark).
1.9.3.5 The system shall track where client entered and exited housing placement, including
D
who referred them and where they went after placement.
1.9.4 Completing Referral Packet: Documenting and assembling all paper work or other information required for a non-Health Agency owned or managed facility to
decide if a referred Client is appropriate.
1.9.4.1 The system shall automatically generate all forms that must be completed to support
HD
referrals to CBOs and network providers.

Appendix C - Functional Requirements (PS-1034) Page 74 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Functional Category Title Section # Description
Billing/Accounting 23.0 Program/Payer Management
26.0 Coding
27.0 Billing/Claims
28.0 A/R Collections
29.0 Electronic Transactions
37.0 Accounts Payable

Appendix C - Functional Requirements (PS-1034) Page 75 of 110
Functional Requirements
1.23 Program Payor Management
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior.Avail. Description
Met
1.23 Program / Payer Management: Entering and maintaining information on the program, payer, or guarantor that is responsible for the cost of a client's care. A client may
have one or more guarantors depending on the client, program, service, or source(s) of payment.
1.23.1 Entering and Maintaining Payer, Program, Plan Information: Capturing information on an unlimited number of Payers/Programs/Plans, including specific benefit
or payment limits. Maintaining numerous, complex rules that establish the sequence in which various payers can be billed for services rendered. Associates funding
to programs and accommodates payer funding and source cascades.
1.23.1.1 The system shall permit authorized staff to define, describe (e.g., narrative), and update
HD
a program/service/plan/payor without vendor support.
1.23.1.2 The system shall track and manage benefit limits, deductibles, co-pays, and covered
HD
and non-covered services for each plan.
1.23.1.3 The system shall capture and maintain details on multiple payors for a client. HD
1.23.1.4 The system shall support multiple fee schedules by payor with specific billing/adjust
HD
rules for each program and/or payor.
1.23.1.5 The system shall manage multiple reimbursement methods including fee for service,
HD
case rates, per diem, capitation and grant-in-aid
1.23.1.6 The system shall assign and maintain a unique identifier for each program. HD
1.23.1.7 The system shall support per program fees. HD
1.23.1.8 The system shall support per session fees. HD
1.23.1.9 The system shall support drug testing fees. HD
1.23.1.10 The system shall support miscellaneous fees. HD
1.23.1.11 The system shall permit adjustments to Client accounts at any point in the billing HD
1.23.1.12 process.
The system shall capture, track and link services delivered to a SLO County
HD
Client/Patient/ client by out-of-network providers.

Appendix C - Functional Requirements (PS-1034) Page 76 of 110
Functional Requirements
1.23 Program Payor Management
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.23.1.13 The system shall define, capture, and track information on any programs from which a
client is recieving service to include:
- Adult Protective Services (APS)
- 26.5 California Childrens Services (CCS)
- Child Welfare Services (CW)
- CalWORKS
D
- Drug Court (DAS)
- ConRep
- Mental Health Services Act
- Probation
- Substance Abuse Block Grant Funding (DAS)
- Any new programs
1.23.1.14 The system shall track different funding sources, including:
- Short-Doyle Medi-Cal
- Drug Medi-Cal
- Medicare
- Healthy Familes
HD
- Funds from other counties
- Insurance
- Thrid Party Payors (e.g., victim witness)
- Grants
- Private pay
1.23.1.15 The system shall flag plan/program recipient services that are the responsibility of
D
another county.
1.23.1.16 The system shall properly handle the sequential billing of payors (e.g. Medicare 1st,
Private Insurance 2nd, Patient 3rd, and Medi-Cal 4th) ensuring that the sequence is
HD
based on both the coverage that the client has and the services that are covered by the
various plans.
1.23.1.17 The system shall maintain a consolidated master list of Client/Patient insurance payors,
D
organized by dates of coverage, and eligibility criteria.

Appendix C - Functional Requirements (PS-1034) Page 77 of 110
Functional Requirements
1.23 Program Payor Management
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.23.2 Entering and Maintaining Guarantor Information: Capturing information on an unlimited number of Payers/Programs/Plans, including specific benefit or
payment limits. Maintaining numerous, complex rules that establish the sequence in which various payers can be billed for services rendered. Associates funding to
programs and accommodates payer funding and source cascades.
1.23.2.1 The system shall accommodate complex billing rules that are specified by a County-
defined structure based on program, clnician and clinic licensure, and funding HD

1.23.2.2 source(s). shall link Client ID with what programs they are enrolled in, what payers
The system
HD
they are eligible to be paid by, and the hierarchy of how the funding applies.
1.23.2.3 The system shall maintain current and historical rates for authorized services by
HD
program / provider in order to ensure payment of rate in force at time of service.
1.23.2.4 The system shall maintain and enforce current and historical billing rules by
program/provider related to system-provided error checks on procedures and services HD
(e.g., lockouts, cap on hours billed for service withing a given program).
1.23.3 Maintaining History: Maintaining a history of eligibility data for each payer and appropriately assigning primary, secondary, and tertiary payers for services based
on County-defined business rules. Maintaining historical rate tables.
No system requirements were identified specific to this process.
1.23.4 Updating All Information: Adjusting information at any time, with changes effected in real-time (e.g., tracks retroactive adjustments for cases in which a client is
added to a program with an effective date prior to the date of service).
1.23.4.1 The system shall permit the updating of the cascade level of insurance plans that have
HD
been changed for a client, and identify clients who have lost their insurance coverage.

Appendix C - Functional Requirements (PS-1034) Page 78 of 110
Functional Requirements
1.26 Coding
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.26 Coding: Selecting, documenting, maintaining and updating standard, industry-wide HIPAA compliant codes related to diagnoses (e.g., DSM-4TR, ICD-9) and procedures
(e.g., CPT, HCPCS). Accurate and appropriate coding is essential to timely and optimal reimbursement for services rendered. Coding includes mapping proprietary vendor,
County, and other program, payer, or plan codes to industry standard codes.
1.26.1 Selecting Appropriate Code: Treating clinician selecting appropriate diagnosis or service code based on clinical judgment, including CPT, DSM, HCPCS, ICD,
E&M codes.
1.26.1.1 System alerts user for errors in coding, including reason for the error message. HD
1.26.1.2 The system shall have system edits that support clinician selection of the proper code. D
1.26.1.3 The system shall enforce the selection of standard and appropriate service codes
HD
according to which services have been authorized for a client.
1.26.1.4 The system shall restrict service codes available to a provider to those services for
HD
which the provider is authorized to charge.
1.26.2 Grouping Codes (PHF): Aggregating individual codes to map to established DRGs.
1.26.2.1 The system shall provide mapping / aggregating of individual codes to established D
DRGs.
1.26.3 Validating Charges: Ensuring that provider documentation in the health record supports diagnosis and all billing-related codes included in claims, bills, or invoices.
1.26.3.1 The system shall maintain procedure codes and associated rates and be able to HD
1.26.3.2 The system shall capture and retain current and past client/patient diagnoses. HD
1.26.4 Maintaining HIPAA-Compliant Code Sets: Maintaining and periodically updating codes as needed (e.g., ICD-10).
1.26.4.1 The system shall support the ICD-9-CM, International Classification of Diseases,
HD
standard code set.
1.26.4.2 The system shall support ICD-10 by October 1, 2013. HD
1.26.4.3 The system shall support the Current Procedure Terminology (CPT) standard code set. HD
1.26.4.4 The system shall support the Diagnostic and Statistical Manual of Mental Disorders
HD
(DSM-IV) standard code set.
1.26.4.5 The system shall maintain and update National Drug Codes (NDC). D
1.26.4.6 The system shall allow County authorized users to maintain and update all reference
tables and libraries without requiring direct vendor support (i..e, diagnosis codes, HD
procedure codes, drug codes, rates, and related reference tables).
1.26.4.7 The system shall provide the ability to establish, maintain, and update crosswalks of
one code set to another (e.g., DSM-IV and ICD-9-CM standard code sets) and to HD
support translate between these code sets according to the established crosswalk..

Appendix C - Functional Requirements (PS-1034) Page 79 of 110
Functional Requirements
1.26 Coding
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.26.4.8 The system shall automatically update standard code sets (e.g., ICD-9, ICD-10, CPT-4
HD
and DSM-IV-TR) in order for system to always have the most recent code tables.
1.26.5 Maintaining Proprietary Codes: Entering and maintaining local or State-specific codes (e.g., creating and maintaining disallowance codes in the new system that
map to State codes for disallowed services.
1.26.5.1 The system shall accommodate user-defined codes that are required at the local or
State level (e.g., disallowance codes). HD

Appendix C - Functional Requirements (PS-1034) Page 80 of 110
Functional Requirements
1.27 Billing Claims
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.27 Billing/Claims (MHS) and Client Statements (DA/S): A billing statement represents a collection of charges for a specific client over a particular period of time. The
billing process involves generating a claim document that documents and substantiates a request for payment of provided services. A billing statement can be generated via
paper forms or electronically. A claim represents a request for payment for services/procedures that have been provided to a client. Services/procedures provided must be
appropriate for the diagnosis in order to receive maximum allowed reimbursement. Claims may be submitted to institutional payers in paper or electronic format. A bill may be
sent to the client for the balance due after claims to all other payer sources have been adjudicated. Includes preparing and sending client statements to DA/S (fee-for-service)
and MHS clients. Encounter: An encounter is a unit of service (or a collection of services) and is the basis for generating claims and bills.
1.27.1 Maintaining Fee Schedule and Structure: Developing annual fees for each program with placeholders for cost of service, State Maximum Amount, or billed charge,
using various methodologies, including creating sliding scales based on UMDAP. Maintaining accurate and up-to-date historical and current information on payer-
specific or County charges for all services rendered and programs offered to clients.
No system requirements were identified specific to this process.
1.27.2 Identifying Program(s): Determining at the point of service, which program(s) a client is eligible for.
No system requirements were identified specific to this process.
1.27.3 Deposit/Payment Collection & Receipting:
1.27.3.1 The system shall capture various methods of client payment (e.g., via drop-down HD
1.27.3.2 The system shall assign a unique receipt number for each payment HD
1.27.3.3 The system shall support point-of-service check-out whereby charges are calculated
and added to previous accounts receivable balances, payments are posted, and payment HD
receipts are issued and printed.
1.27.3.4 The system shall permit the posting of payments to a client account even if there are no
corresponding charges, and handles such payments as credit balances to be matched HD
with charges at a later date.
1.27.4 Capturing Fees/Charges: Capturing billable services by linking back to rosters that document services received by virtue of a client's attendance at group or
individual counseling or treatment sessions.
1.27.4.1 The system shall capture all charges for unscheduled (Non-rostered) drug tests (e.g.,
HD
outside lab charges and labor costs of County staff dedicated to lab testing).
1.27.4.2 The system shall recognize revenue, adjusted revenue, contractual allowances and
sliding scale adjustments for each service from all sources at the time of entry based on HD
the billing rules entered for insurance companies and self-pay clients.
1.27.4.3 The system shall support charges recorded at standard fees and any contractual HD
1.27.4.4 recorded as adjustments to the standard
allowances or sliding scale discounts areaccounting with the default of posting fees.
The system shall provide for Open-item
HD
payments and adjustments to specific charges/invoices.

Appendix C - Functional Requirements (PS-1034) Page 81 of 110
Functional Requirements
1.27 Billing Claims
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.27.5 Payer and Client Statements (Billing): Generating statements indicating services provided for a specified date range, including client name, payer name, programs,
date/time/type of services rendered, date and amount of all deposits/payments received, outstanding balance, due date, etc.
1.27.5.1 The system shall calculate, bill and track client co-pays and deductibles. HD
1.27.5.2 The system shall calculate, bill and track client Share of Cost (SOC) Medi-Cal. HD
1.27.5.3 The system shall calculate, bill and track the California Drug and Alcohol Program
sliding scale requirements that include billing a pre-calculated monthly total, a pre- HD
calculated per episode total, or per visit charges (depending on service type).
1.27.5.4 The system shall support other user-defined sliding scales, calculation of transfer in
HD
and out balances, and budget payment plans.
1.27.5.5 The system shall permit retroactive enrollment data to produce Medi-Cal claims for
services originally billed to other sources that are now Medi-Cal eligible, and make the HD
proper adjustments to appropriate revenue, receivable and adjustment accounts.
1.27.5.6 The system shall permit retroactive Medi-Cal billing for up to 18 months after the
HD
original date of service.
1.27.5.7 The system shall produce user-defined, detailed client statements on demand. HD
1.27.5.8 The system shall produce user-defined detailed client statements on a cycle basis (e.g.
HD
every month).
1.27.5.9 The system shall permit authorized user to disable the production of statements for any
HD
client.
1.27.5.10 The system shall be able to classify clients into categories for which the user will have
control over the decision to print statements (e.g., all clients under 100% of the federal HD
poverty level are not sent statements).
1.27.5.11 The system shall permit reversal of charges on a bill (i.e., pulling out non-permitable
HD
charges).
1.27.5.12 The system shall generate a billing statement that reflects services provided, regardless
HD
of client's account status or payment liability.
1.27.5.13 The system shall generate electronic or harscopy bills for Medi-Cal clients/patients. HD
1.27.5.14 The system shall generate a bill for services with or without diagnosis code. HD
1.27.5.15 The system shall identify Medi-Cal retroactive eligibility and bill for covered services. HD
1.27.5.16 The system shall permit authorized staff to suppress bills or other materials from being
HD
printed or displayed according to user-defined parameters.
1.27.5.17 The system shall generate CMS 1500 bills. HD
1.27.5.18 The system shall generate UB04 bills. HD

Appendix C - Functional Requirements (PS-1034) Page 82 of 110
Functional Requirements
1.27 Billing Claims
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.27.5.19 The system shall generate Superbills. HD
1.27.5.20 The system shall support both real-time (i.e., DDE) and batch billing (i.e., claims)
HD
methods for any given client.
1.27.5.21 The system shall bill the right funding source for the right program (e.g., Growing
HD
Grounds program: if Conrep client, billed as Conrep; if not Conrep, not billable).
1.27.5.22 The system shall permit authorized staff to perform post-payment adjustments. HD
1.27.5.23 The system shall detect and prevent billing of low balance claims. HD
1.27.5.24 The system shall track each service provided, billed, and the amount paid, denied, or
HD
suspended at the client account level.
1.27.5.25 The system shall have the ability to print payer/client statements. HD
1.27.5.26 The system shall print or display a bill in chronological order for: Encounters HD
1.27.5.27 The system shall print or display a bill in chronological order for: Treatments HD
1.27.5.28 The system shall print or display a bill in chronological order for: Receipt number HD
1.27.5.29 The system shall print or display a bill in chronological order for: Date received HD
1.27.5.30 The system shall print or display a bill in chronological order for: Payor HD
1.27.5.31 The system shall print or display a bill in chronological order for: Payments HD
1.27.5.32 The system shall print or display a bill in chronological order for: Adjustments and/or
HD
rate changes
1.27.5.33 The system shall print or display a bill in chronological order for: Share-of-cost
HD
adjustments
1.27.5.34 The system shall print or display a bill in chronological order for: Payments HD
1.27.5.35 The system shall print or display a bill in chronological order for: Billings HD
1.27.6 Payer Invoice (Billing): Generating invoices to payers for Contracts and Grants for internal services provided.
1.27.6.1 The system shall support the ability to bill third party payor sources. HD
1.27.6.2 The system shall support the authorization for payment to and reimbursement of third
HD
party payors.
1.27.6.3 The system shall produce paper claims for any service transaction on-demand and in a
HD
batch mode.
1.27.6.4 When Remittance Advices are posted, the system shall automatically transfer
outstanding charges to secondary and tertiary payors and/or client responsibility, and HD
produce the appropriate electronic and/or paper claim (forms).
1.27.6.5 The system shall automatically calculate payments due applying appropriate pre-
HD
determined contractual terms.

Appendix C - Functional Requirements (PS-1034) Page 83 of 110
Functional Requirements
1.27 Billing Claims
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.27.6.6 The system shall automatically compute and write-off the positive or negative
HD
contractual allowance amounts for bills, including capitated or grant-in-aid funding
1.27.6.7 streams.
The system shall automatically bill or invoice per contract terms and conditions, and
automatically make contractual adjustments (e.g., if $1200 for PHF day and contract
HD
with insurer is for $800, system bills insurance $800 and makes contractual adjustment
of $400).
1.27.6.8 The system shall permit authorized staff to adjust claims and provide an audit trail for
HD
payment and charge adjustments.
1.27.6.9 The system shall perform automatic drug Medi-Cal billing with internal checks for
HD
group size, correct diagnosis, etc.
1.27.6.10 The system shall prohibit billing for services that were provided without prior
HD
authorization or approved treatment plans.
1.27.6.11 The system shall permit authorized staff to perform post-payment adjustments. HD
1.27.6.12 The system shall display and print payer invoices. HD
1.27.6.13 The system shall print or display a bill in chronological order for: Type of billing
HD
(Medicare, Medi-Cal, co-pay, private insurance, etc.)
1.27.7 Daily Cash Journal: Reconciling payments received during a given date range. Reconciling by site/location (e.g., Atascadero, Arroyo Grande, San Luis Obispo),
program (e.g., DUI, TX, P36), pay source type (e.g., cash, credit, money order, web, check), and payment for (e.g., program, testing, miscellaneous).
1.27.7.1 The system shall provide the ability to reconcile cash payments received against cash
recievd posting log (i.e., for what service, how much, from whom, where received, and HD
in what form of payment).

Appendix C - Functional Requirements (PS-1034) Page 84 of 110
Technical Requirements
1.28 AR
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.28 AR/Collections: The process of monitoring outstanding claims/bills, associating payments received with claims/bills issued, and following up on delinquent accounts.
D/AS outsources its collections function to the Probation Department.
1.28.1 Monitoring Status of Client Accounts: On an ongoing basis, tracking deposits and payments received from clients against programs/services rendered and client's
liability, and determining accounts and amounts due that are current, 30 days, 60 days, etc.
1.28.1.1 The system shall support the generation of invoices for services provided. HD
1.28.1.2 The system shall determine the appropriate code/rate for invoice processing. HD
1.28.1.3 The system shall track data by invoice-processing information (e.g., Tax ID, Agency,
HD
Provider Name) and client identifier.
1.28.1.4 The system shall support the entry of point-of-service check-out whereby charges are
calculated and added to previous accounts receivable balances, payments are posted, HD
and payment receipts and account statements are issued.
1.28.1.5 The system shall reconcile the following against deposit receipts: client, payer source
HD
(e.g., Grants, Medi-Cal), date of service, billed amount, and paid amount.
1.28.1.6 The system shall permit adjustment of receivables for:
Account adjustments HD
Therapeutic adjustments (waiver).
1.28.1.7 The system shall permit adjustment of receivables for: retroactive rate adjustments. HD
1.28.1.8 The system shall permit adjustment of receivables for: forgiven debt waiver (i.e., write-
HD
offs).
1.28.1.9 The system shall allow remaining balances to be released upon case closure and
HD
redirected to other sources.
1.28.1.10 The system shall print or display the transaction history for a specific client account,
including all charges, payments, and adjustments for all payors for a specified date HD
range.
1.28.1.11 The system shall print or display the transaction history for a group of client accounts,
including all charges, payments, and adjustments for all payors for a specified date HD
range.
1.28.1.12 The system shall print or display the transaction history for a specific payor, including
HD
all charges, payments, and adjustments for a specified date range.
1.28.1.13 The system shall print or display the transaction history of client responsibility,
HD
including all charges, payments, and adjustments for a specified date range.

Appendix C - Functional Requirements (PS-1034) Page 85 of 110
Technical Requirements
1.28 AR
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.28.1.14 The system shall print or display the transaction history for all payors, including all
HD
charges, payments, and adjustments for a specified date range.
1.28.2 Identifying Delinquent Accounts: Identifying clients who have either not had a face-to-face encounter in 60 days, or who have not made a payment in 60 days.
1.28.2.1 The system shall notify clinicians/therapists when a client on their caseload has not had
HD
a face-to-face encounter in 60 days
1.28.2.2 The system shall notify clinicians/therapists when a client on their caseload has not
HD
made a payment in 60 days
1.28.3 Sending Accounts to Collections: Since DA/S collection is outsourced, the process of collection involves sending delinquent account information to Probation
Collections, and receiving and posting collections payments
1.28.3.1 The system shall allow a user to append notes captured during a collection call to the
appropriate transaction and generate ticklers based on follow-up dates defined by the HD
user.

Appendix C - Functional Requirements (PS-1034) Page 86 of 110
Functional Requirements
1.29 Electronic Transactions
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.29 Electronic Transactions: Exchanging structured data, using agreed-upon HIPAA-compliant transaction and code sets, from one entity to another (e.g., electronic claims
submission).
1.29.1 Maintaining All HIPAA-Compliant Transactions: Sending and receiving HIPAA-compliant transactions, as required.
1.29.1.1 The system shall comply with all HIPAA ASC X12N transaction set requirements. HD
1.29.1.2 The system shall be compliant with the ASC X12N 270/271 - Health Care Eligibility
HD
Benefit Inquiry and Information Response format.
1.29.1.3 The system shall be compliant with the ASC X12N 276/277 - Health Care Claim -
HD
Status Request and Response format.
1.29.1.4 The system shall be compliant with the ASC X12N 278 - Health Care Services Review
HD
- Request to Review and Response format.
1.29.1.5 The system shall be compliant with the ASC X12N 834 - Benefit Enrollment and
HD
Maintenance format.
1.29.1.6 The system shall be compliant with the ASC X12N 835 - Health Care Claim -
HD
Payment/Advice format
1.29.1.7 The system shall be compliant with the ASC X12N 837P - Health Care Claim -
HD
Professional
1.29.1.8 The system shall be compliant with the ASC X12N 837I - Health Care Claim -
HD
Institutional
1.29.1.9 The system shall maintain 835 and 837 formats that are properly matched to the
HD
California Department of Mental Health requirements.
1.29.1.10 The system shall maintain 835 and 837 formats that are properly matched to the
HD
California Alcohol and Drug Program requirements.
1.29.1.11 The system shall maintain 835 and 837 formats that are properly matched to the
HD
California Medi-Cal requirements.
1.29.1.12 The system shall maintain 835 and 837 formats that are properly matched to the
HD
California Drug Medi-Cal-specific requirements.
1.29.1.13 The system shall support standard encounter formats, either proprietary or industry-
HD
standard (837P).
1.29.1.14 The system shall comply with X12 Version 5010 counterparts to the 4010A1
HD
Implementation Guides as currently mandated under HIPAA.
1.29.1.15 The system shall support electronic transfer of data to/from Medicare. HD
1.29.1.16 The system shall support electronic transfer of data to/from Medi-Cal. HD

Appendix C - Functional Requirements (PS-1034) Page 87 of 110
Functional Requirements
1.29 Electronic Transactions
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.29.1.17 The system shall support electronic transfer of data to/from Targeted Case
D
Management (TCM).
1.29.1.18 The system shall support electronic transfer of data to/from Medi-Cal Administrative
HD
Activities (MAA).
1.29.1.19 The system shall support electronic transfer of data to/from third-party payors. HD
1.29.1.20 The system shall support electronic transfer of data to/from CalOMS. HD
1.29.1.21 The system shall support electronic transfer of data to/from Healthy Families. HD
1.29.2 Internet Payments: Accepting online credit card payments from active clients.
1.29.2.1 The system shall permit active clients to make payments on their account using a
D
personal credit card.

Appendix C - Functional Requirements (PS-1034) Page 88 of 110
Functional Requirements
1.37 AP

Requirement How
Prior. Avail. Description
Met
1.37 AP/Reimbursement: The process of monitoring and making payments (e.g., reimbursement or compensation) due to providers for services rendered to clients.
Provider reimbursement methodologies may include fee-for-service (FFS) agreements, under which a provider is paid full charges for each service rendered; a
capitation agreement under which the provider receives a set fee per month for each client under his/her care; a mixture of both FFS and capitation; cost-based
reimbursement; negotiated rate reimbursement; or other contractual arrangements.
1.37.1 Determining Types of Reimbursement: Support the different methods of provider reimbursement, which may be based on salary, fee schedules, fee-for-service, and
capitation with performance/risk factors.
No system requirements were identified specific to this process.
1.37.2 Preparing Payment/Claims Adjudication: Provider reimbursement is calculated or determined based on contractual agreements, claims submission, and other
requirements (e.g., utilization management and risk sharing). Payment can be made via paper check or electronic funds transfer.
1.37.2.1 The system shall permit authorized network providers to enter CMS 1500 claims
HD
directly into the system.
1.37.2.2 The system shall accept scanned hard-copy paper claims (e.g., from billing companies
HD
used by certain network providers; from network providers who do not have e-mail).
1.37.2.3 The system shall automatically compare a contractor invoice to contract terms and
D
conditions (contract compliance) and notify staff of discrepancies.
1.37.2.4 The system shall compare invoiced service units for a given period against services
D
entered into the system by a contract provider and notify staff of discrepancies.
1.37.2.5 The system shall screen Claims for proper eligibility including whether other insurance
HD
plans are primary.
1.37.2.6 The system shall screen Claims for proper eligibility including the existence of an
HD
appropriate authorization.
1.37.2.7 The system shall screen Claims for proper eligibility including coverage for the specific
HD
service under the authorization.
1.37.2.8 The system shall screen Claims for proper eligibility including service by an authorized
HD
provider.
1.37.2.9 The system shall adjudicate claims on a per claim basis. HD
1.37.2.10 The system shall permit pending claims to be reviewed and denied if they do not have
HD
an appropriate authorization in the system.
1.37.2.11 The system shall permit claims that have been entered, adjudicated, approved, and paid
D
to be reversed.

Appendix C - Functional Requirements (PS-1034) Page 89 of 110
Functional Requirements
1.37 AP

Requirement How
Prior. Avail. Description
Met
1.37.2.12 The system shall generate accounts payable transactions for interface to the County
D
SAP accounting system (e.g., Network Provider, Managed Care).
1.37.2.13 The system shall automatically credit contractual allowances and other adjustments to
HD
accounts during payment posting based on pre-determined, carrier-specific criteria.
1.37.2.14 The system shall report Denial notices to providers for specific reasons, including but
not limited to: Claim is incomplete, Client/Patient is not eligible, Provider is not
eligible, Service dates do not match authorized dates, Service is not authorized, HD
Diagnosis is not included in Scope of Benefits (specialty mental health carve-out),
Retroactive coverage is not available, and Billing submittal is past the limitation period.
1.37.2.15 The system shall report on the activities and running balance of each account. HD
1.37.3 Providing Payment: Payment is provided on a timely basis.
1.37.3.1 The system shall generate a remittance advice by legal entity and/or by provider. HD
1.37.3.2 The system shall generate a remittance advice for each service paid that includes:
Authorization Number, Service Date, Client/Patient Name, Amount Paid, Share-of-
HD
Cost (if applicable), Claims Paid, Claims Denied and Reason, Claims Suspended and
Reason, etc.
1.37.3.3 The system shall permit adjustments to the Remittance Advice for specific
D
providers/facilities.
1.37.3.4 The system shall permit the user to choose whether to include or exclude Denials and
HD
Pended Claims from Remittance Advice reports.
1.37.4 Coordination of Benefits: The COB (Coordination of Benefits) process determines the respective responsibilities of two or more health plans or payers that have
some financial responsibility for a claim. A coordination of benefits, or "non-duplication," clause in either policy prevents double payment by making one insurer the
primary payer, and assuring that not more than 100 percent of the cost is covered. Standard rules determine which of two or more plans, each having COB provisions,
pays its benefits in full and which becomes the secondary payer on a claim (also called Cross-Over).
1.37.4.1 The system shall support coordination of benefits for Medi-Cal, Medicare, and other
payors. (Note: COB/EOB coordination plus additional California Short-Doyle Medi- HD
Cal process changes.)
1.37.5 Explanation of Benefits: Explanation of Benefits (EOBs) are paper statements-- or electronic exchange of information-- provided by the payer (including the county)
that reconcile the amount billed to the amount paid, and indicate the reason(s) an item was not paid. The EOP also includes the amount of any charges that are the
responsibility of the client (e.g., shall automatically create the Notice
1.37.5.1 For denied payments, the systemco-payment, coinsurance, deductible).of Action-C
HD
(NOA-C) using information on the Explanation of Benefit.

Appendix C - Functional Requirements (PS-1034) Page 90 of 110
Functional Requirements
1.37 AP

Requirement How
Prior. Avail. Description
Met
1.37.5.2 The system shall track claims and payments made to out-of-network providers (e.g., an
out-of-network FFS psychiatrist who saw and billed for a SLO County patient D
receiving inpatient services outside of the County) and automatically generate EOBs.
1.37.6 Disallaowance: Disallowances are services that have not been--or will not be--reimbursed for a variety of reasons. Handling disallowances entails entering the
unreimbursed service(s) and the reason(s) for non-payment using State and County codes. Disallowances must be entered in the County system and in the State
system to capture detail on the service(s) and reason(s) for non-payment.
1.37.6.1 The system shall flag "disallowed services" using County and State "reason" codes at
HD
any stage in the billing process.
1.37.7 Updating Reports: Payment records are updated to ensure accuracy and reliability. Payment records are posted to the general ledger, A/P and A/R as needed (e.g.,
recovery operations).
1.37.7.1 The system shall provide a comment field restricted access by accounting staff (i.e., not
part of the client record) for capturing text-based narrative, explanations, or comments HD
related to accounts payable.

Appendix C - Functional Requirements (PS-1034) Page 91 of 110
San Luis Obispo
Behavioral Health Department
Behavioral Health Electronic Healthcare Record System (BHEHR)

Functional Category Title Section # Description
Administration/Reporting 25.0 Census
30.0 Compliance/Audit
31.0 Reporting
32.0 Compaints, Grievances, Appeals, NOA, State Hearings
33.0 Licensing/Credentialing
38.0 Performance Quality Improvement
39.0 Community Ed & Outreach

Appendix C - Functional Requirements (PS-1034) Page 92 of 110
Functional Requirements
1.25 Census
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.25 Census: The census is the official count of the number of active clients or patients as of a specific date/time or date range. Some programs require a daily census (e.g.,
inpatient PHF and intensive day care services) whereas others may require less frequent, periodic census counts (e.g., DUI programs). The census is essential to manage
capacity and to comply with payer requirements that may be driven by room and board.
1.25.1 Counting Inpatients/ Active Clients: Counting the number of active clients in a specific program or setting as of a pre-determined day/date/time, based on a pre-
determined frequency. In the inpatient PHF setting, the census is captured three times a day.
1.25.1.1 The system shall capture and track census for patients in inpatient settings. HD
1.25.1.2 The system shall capture and track census for clients in outpatient settings. HD
1.25.1.3 The system shall capture and track inpatients by unit, room and bed. HD
1.25.1.4 The system shall support documentation of midnight bed checks. HD
1.25.1.5 The system shall generate Facility Alphabetical Rosters showing Client/Patient name
HD
and location within facility, physician, insurance, and phone number
1.25.2 Managing Census: Managing inpatient discharges and transfers to accommodate new or pending admissions (PHF). Managing active clients to accommodate clients
on the wait list (D/AS).

No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 93 of 110
Functional Requirements
1.30 Compliance

Requirement How
Prior. Avail. Description
Met
1.30 Compliance / Auditing: Meeting accreditation, regulatory, legal, and payer requirements. Compliance includes: implementing written P&P and standards of conduct;
designating officer and committee; conducting effective training and education; developing effective lines of communication; enforcing standards through well publicized
disciplinary guidelines; developing policies addressing dealings with sanctioned individuals; conducting internal monitoring and auditing; responding promptly to detected
offenses; developing corrective actions; reporting to the Government. Auditing is a process of examining current practices to ascertain or verify conformance with pre-
established requirements. Supporting all data analysis and reporting needs related to certifications, regulation, legislation, legal, DMH, WIC, Title IX, NNA, Medicare, Medi-
Cal, grants, HIPAA, County policies and procedures, internal/external chart audits, CBO security access, and audit criteria setting.
1.30.1 The system shall automatically assign a unique transaction number for every
HD
transaction in the system (e.g., to support audits).
1.30.2 The system shall establish an electronic audit trail on checks received. HD
1.30.3 The system shall support electronic audits regardless of a user's current location (i.e.,
HD
not requiring having to go to the clinic).
1.30.4 The system shall provide automatic quality assurance checks based on business rules
(e.g., system automatically tracks compliance with requirement to provide client an HD
appointment for service within 21 days of the first contact based on system calculation).
1.30.5 The system shall generate reports that identify discrepancies where the progress note
HD
date does not match the attendance date.
1.30.6 The system shall permit authorized users at Community-Based Organizations (CBOs)
D
to access compliance information.
1.30.7 The system shall provide the capability to track County compliance with
D
documentation standards and regulations.
1.30.8 The system shall compile and maintain necessary data for compliance reporting
D
required by State, Federal, and other agencies that regulate County.
1.30.9 The system shall provide the capability for authorized staff to define required activities
D
and establish a workflow template for a given type of audit that can be saved for reuse.
1.30.10 The system shall generate and send notification(s) to County staff involved in audit
D
activities regarding County-defined audit events and compliance status.
1.30.11 The system shall allow authorized users to query the status of activities related to
D
specific audits.
1.30.12 The system shall generate and send notifications to authorized users when audit
D
activities are approaching deadlines.

Appendix C - Functional Requirements (PS-1034) Page 94 of 110
Functional Requirements
1.30 Compliance

Requirement How
Prior. Avail. Description
Met
1.30.13 The system shall generate reports specific to audit status, outstanding activities, and
D
percent completion of specific audits.
1.30.14 The system shall provide the capability for authorized users to enter information
D
regarding resolution of audit activities
1.30.15 The system shall provide the capability for authorized users to enter corrective actions
D
resulting from audits
1.30.16 The system shall provide the capability for authorized users to enter and update audit
D
results.
1.30.17 The system shall provide the capability to establish a work queue for coding review
D
prior to billing and/or claim submittal.

Appendix C - Functional Requirements (PS-1034) Page 95 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31 Reporting: Reporting is the aggregation of financial, operational, and clinical data into meaningful information that facilitates decision-making, supports
compliance/auditing needs, and meets mandated reporting requirements (e.g., CSI, CalOMS, and Medi-Cal cost reports). Standard reporting adheres to a pre-determined format
and data types and is produced on a routine basis. Ad-hoc reporting generates reports containing user-requested data on an as-needed or on-demand basis.
1.31.1 General:
1.31.1.1 The system shall provide all standard reports as defined by County. (Note: Refer to the
HD
Procurement Library for standard reports currently used by County.)
1.31.1.2 The system shall have standard reports providing a variety of views of County
administrative and clinical operations such as monthly trend reports, clinician
HD
comparison reports, etc. that provide summarized management-related data and that
support tactical and strategic decision-making.
1.31.1.3 The system shall allow for the selection and filtering of report parameters by key
HD
variables such as date range, department, and clinician.
1.31.2 Generating Administrative Reports:
1.31.2.1 The system shall provide reports on contact statistics (e.g., volume and type of
inquiries, turnaround time, and number of abandoned calls) for contact management D
(i.e., Central Access) and call intake activities.
1.31.2.2 The system shall provide reports on wait-listed clients. HD
1.31.2.3 The system shall generate statistical reports to the State Department of Alcohol And
Drug Programs identifying program census of clients treated and/or awaiting drug and HD
alcohol treatment. Includes the Drug and Alcohol Treatment Access Report (DATAR).
1.31.2.4 The system provides reporting capability to identify clients that may be eligible for
HD
Medi-Cal based on multiple criteria.
1.31.2.5 The system shall provide reporting capability that identifies any changes in a client's
HD
eligibility for service (by payor, funding source).
1.31.2.6 The system shall provide reporting capability that identifies client eligibility for
HD
coverages other than Medi-CAL (e.g., Medicare, insurance, private pay).
1.31.2.7 The system shall generate reports that identify aid code(s) by client/patient HD

Appendix C - Functional Requirements (PS-1034) Page 96 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31.2.8 The system shall generate appointment disposition reports by clinic or by provider for
County-defined date range to include:
Appointments kept D
Cancellations
No-shows
1.31.2.9 The system shall produce reports listing appointments by provider for user-defined date
D
ranges.
1.31.2.10 The system shall provide a roster of current staff with contact information for routine
D
communication.
1.31.3 Generating Clinical Reports:
1.31.3.1 The system shall track and report on statistics regarding authorizations including:
Submissions
Approvals
Denials HD
Provider type
Age of authorization
Other parameters as defined by the County
1.31.3.2 The system shall provide reports that indicate the trending of authorizations by the
following:
Referring provider
Referred to provider HD
Referred to provider specialty
Authorization status (approved/denied/pended)
Any combinations of above
1.31.3.3 The system shall produce authorization productivity reports by authorizing user. HD
1.31.3.4 The system shall produce authorization turnaround report. HD
1.31.3.5 The system shall provide standard reports on unauthorized services by the following
parameters:
Client
HD
Provider
Status of authorization (none, pending, denied, violated)
Service Provider not authorized for (facility, program, payor, population, service)

Appendix C - Functional Requirements (PS-1034) Page 97 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31.3.6 The system shall track and report on the number of open cases/episodes by:
Active clients or programs
Inactive clients or programs HD
Provider, location, and diagnosis
Unduplicated
1.31.3.7 The system shall track and report on the number of case/episodes opened and/or closed
HD
during a user-defined period of time by provider, location, and diagnosis.
1.31.3.8 The system shall track and report on a client by:
Number of cases involving client
HD
Diagnosis (e.g., Primary, Secondary, Tertiary; Axis I-V)
Location where services are being provided to client
1.31.3.9 The system shall capture and report each client/patient who has been evaluated for
HD
5150 status and disposition of each evaluation
1.31.3.10 The system shall track and repor on the number of cases, either by program or total,
HD
assigned to a provider (e.g., Network and County employed providers).
1.31.3.11 The system shall generate reports that indicate active cases by funding source HD
1.31.3.12 The system shall track and report on service activity for user-defined time periods by
one or more of the following parameters:
Client, provider
Facility HD
Service
Dates of service
Other County-defined parameters
1.31.3.13 The system shall provide a standard report on services without supporting progress HD
1.31.3.14 notes.
The system shall capture and generate reports on the number of clients/patients
HD
recieving services per location.
1.31.3.15 The system shall track and report clients/patients currently receiving services in any
Drug Courts, including but not limited to: Adult (Levels 1, 2, 3), Juvenile, Mental HD
Health, Dependency, etc.)

Appendix C - Functional Requirements (PS-1034) Page 98 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31.3.16 The system shall track clients/patients by housing arrangement to include:
Assisted Living
Board and Care
HD
Transitional Housing
State/Private Hospital
Institute of Mental Disease (IMD)
1.31.3.17 The system shall generate bed rosters by unit and occupancy reports for all Agency
HD
owned or managed beds.
1.31.3.18 The system shall automatically calculate and generate Length of stay (LOS) reports
where LOS is calculated by counting the day entering placement, but not counting the HD
day of discharge.
1.31.3.19 The system shall automatically generate a 26.5/AB 3632 Assessment Report that shows
HD
all clients in this category by site and status.
1.31.3.20 The system shall provide the capability for authorized users to generate a report of
HD
information disclosures for user-defined time periods.
1.31.3.21 The system shall generate reports related to client movement (i..e, ADT). HD
1.31.3.22 The system needs to be able to report service and outcome
information related to special populations such as Homeless and CSOC HD
consumers.
1.31.4 Generating Financial Reports:
1.31.4.1 The system shall generate a history of: Payments received, Treatments, Date of Billing HD
1.31.4.2 The system shall generate a history of Medi-Cal, Medicare, Insurance, Private Pay, HD
1.31.4.3 Other
The system shall generate a history of Balance and reconcile receivables with receipt
HD
number
1.31.4.4 The system shall have the ability to itemize and extract costs, bills, receivables, and
collections by Location, Program, Provider, Service Type, Case Number, Funding HD
Source, Service Function Code, Mode of Service, and Legal Entity.
1.31.4.5 The system shall maintain Case cost information by: Individual client/patient (listed
HD
from high to low cost)
1.31.4.6 The system shall maintain Case cost information by: Family (listed from high to low
HD
cost of service)

Appendix C - Functional Requirements (PS-1034) Page 99 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31.4.7 The system shall maintain Case cost information by: Individual provider (both contract
HD
Network private providers and County employees)
1.31.4.8 The system shall maintain Case cost information by: Stratified case type (e.g. less
HD
intensive or more intensive)
1.31.4.9 The system shall maintain Case cost information by: Region of the County (e.g., ZIP
HD
code)
1.31.4.10 The system shall maintain Case cost information by: Facility or school location at
HD
which services are provided (site location table)
1.31.4.11 The system shall generate claims report that itemizes: Claims paid, Claims denied, and
HD
Claims suspended and reasons
1.31.4.12 The system shall permit sorting claims report by provider, and by date range. HD
1.31.4.13 The system shall generate reports based on payor type to include: Medicare, Medi-Cal,
HD
private pay, Healthy Familes, and other payor types not yet identified.
1.31.4.14 The system shall itemize, extract, and report on costs by one or more of the following
parameters: Service Location, Program, Provider, Service type, Case number, Funding HD
Source, Date/Time (individual or range).
1.31.4.15 The system shall summarize non-billeable activities by provider, by staff, and by HD
1.31.4.16 service.
The system shall compile service units and charges into the Medi-Cal and Medicare
cost reporting categories to produce reports that will support the development of these HD
annual cost reports.
1.31.4.17 The system shall generate appropriate reports as needed and on a timely basis (via
HD
paper forms, on-line screen, etc).
1.31.4.18 The system shall generate reports with summary-level data according to user-defined
HD
criteria, such as subtotals by payor, payor class, program, location, etc.
1.31.4.19 The system shall provide detailed aged accounts receivable reports with user-defined
HD
sort and subtotal criteria including payor, provider, client, program, location, etc.
1.31.4.20 The system shall report the total amount billed by: Case/client HD
1.31.4.21 The system shall report the total amount billed by: Number of appointments HD
1.31.4.22 The system shall report the total amount billed by: 100% appointment / billing,
HD
(exception report of appointment not billed)
1.31.4.23 The system shall report the total amount billed by: The entire history of a client/patient
HD
account.

Appendix C - Functional Requirements (PS-1034) Page 100 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31.4.24 The system shall permit authorized staff to print or display Bills and re-bills to clients,
HD
patients and/or third-party payors (individually or batch).
1.31.4.25 The system shall permit authorized staff to print or display Notification to client/patient
HD
of provider claim approval.
1.31.4.26 The system shall generate a report on total amounts billed and total amounts recieved
HD
in a month.
1.31.4.27 The system shall generate an account-specific A/R aging report for claims over:
30 days
60 days
HD
90 days
80 days
User-defined time periods
1.31.4.28 The system shall generate A/R Aging Reports by client, by program/service, and by
HD
funding source that include: amount billed, amount received, amount adjusted.
1.31.4.29 The system shall generate a report of denied and/or rejected claims. D
1.31.4.30 The system shall generate exception reports. D
1.31.4.31 The system shall generate unbilled claims status report. D
1.31.4.32 The system shall generate rejected claims status report. D
1.31.4.33 The system shall generare a report that reflects payments received and credited to
D
Client/Patient accounts by payor source and date or date range.
1.31.4.34 The system shall provide a report on all insurance billing and reimbursement activity
D
for a specific Client/Patient.
1.31.4.35 The system shall provide reports showing the status of staff credentialing and licensing,
D
including expiration dates.
1.31.5 Generating External (i.e., State) Reports:
1.31.5.1 The system shall automatically generate State-required reports using prescribed data
HD
elements, formats, and frequencies
1.31.5.2 The system shall generate error reports to detect missing or incomplete data elements
HD
prior to electronic transmittal to State, e.g. null fields
1.31.5.3 The system shall provide a consolidated report regarding client movement and
D
discharge data reporting that complies with OSHPD requirements.
1.31.5.4 The system shall provide information for the OSHPD Annual Utilization Report
D
(www.alirts.oshpd.ca.gov)

Appendix C - Functional Requirements (PS-1034) Page 101 of 110
Functional Requirements
1.31 Reporting
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.31.5.5 The system shall generate State mandated reports on a 24-hour basis documenting total
D
licensed staff working by staff classification and by shift for user-defined timeframes.
1.31.5.6 The system shall produce a MHS Medi-Cal Cost Report. D

Appendix C - Functional Requirements (PS-1034) Page 102 of 110
Functional Requirements
1.32 NOA
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.32 Complaints, Grievances, Appeals, Notice of Actions, State Hearings: Complaints, grievances, appeals, Notice of Actions, and State Hearings represent escalating levels
of action available (depending on payer, program, and county policies and procedures) that can be taken when a client, provider, family member, or advocate contests a decision
concerning denial of services or other issues deemed as unacceptable. Complaints are either informal verbal or formal, written expressions of dissatisfaction. DA/S requires that
verbal complaints be put in writing. Grievances are formal, written expression of a complaint, typically initiated by a client against a provider or payer, concerning an alleged
breach of agreement or an alleged injustice. Appeals are filed when a client disagrees with the adjudication of a grievance. A Notice of Action (NOA) is typically generated by
a health plan, and constitutes notification to a client or other appropriate party regarding a denial, termination, reduction, or modification of requested services. State Hearings
represent a formal State process that an individual may initiate against the county if he/she believes the county action is not correct.
1.32.1 Responding to a Case: Certain process and procedures are set up to respond to an incidence/case on a timely basis (via telephone, letters, e-mail, fax, Internet,
intranet, etc.). The response has significant implication on legal, clinical, and financial risk management.
No system requirements were identified specific to this process.
1.32.2 Documenting Appeals, Grievances, & NOAs: All relevant information about the appeals, grievances, and NOAs (NOA-A, NOA-B, NOA-C) are compiled and
analyzed. Certain incidence can be related to quality or utilization management, HIPAA-compliant (privacy, security), and litigation, so appropriate and accurate
information needs to be documented on a timely basis. Notice of Action (NOA) informs Medi-Cal beneficiaries of denial of eligibility based on medical necessity
criteria (NOA-A), or changes in provider-requested mental health services from the MHP (NOA-B), and the beneficiary's rights for appeal if they don't agree with the
MHP decision. Note: NOA-A and NOA-B are interim forms that are translated into other languages after they have been finalized.
No system requirements were identified specific to this process.
1.323 Determining the Response: Based on results from available information or from research, responses to appeals, grievances, and NOAs are identified and
documented.
1.32.3.1 The system shall automatically generate a Notice of Action, as appropriate, based on
D
information entered in the Service Request Form.
1.32.3.2 The system shall automatically generate a Notice of Action, as appropriate, if a
D
network provider rendered a service without receiving prior approval.
1.32.4 Communicating the Response: Timely communication to Client concerning the outcome or decision rendered (e.g., Managed Care sends the Client a Notice of
Action that informs the Client that they are not eligible to receive services).
No system requirements were identified specific to this process.
1.32.5 Performing Tracking and Follow-up
No system requirements were identified specific to this process.
1.32.6 Managing Quality and Performance of the Process: Evaluating the quality and performance of the process for improvements.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 103 of 110
Functional Requirements
1.33 Credentials License
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.33 Licensing/Credentialing: Credentialing is the administrative process of validating the qualifications of licensed professionals (including Health Agency staff, contract and
network provider staff, organizational members or organizations) and checking their background and legitimacy. TThe County outsources some licensing/credentialing activities
to an outside credentialing organization and performs some activities in-house. Licensing/credentialing includes checking, certifying, and credentialing facility licenses. NOTE:
This may be provided by an interface with another County system.
1.33.1 Identifying Qualification Criteria: Establishing the criteria that a clinician must posses in order to provide services. Such criteria include education, training
(residency), experience, license (board certification), accreditation, hospital privileges, malpractice insurance, malpractice liability and claim history, provisions of
emergency care and backup, tax information, and other profile data.
No system requirements were identified.
1.33.2 Submitting Application/ Credential Request: The process for provider to request authorization to practice, such as completion of application or letter of request
(paper form, electronically), and conversation with County Medical Director or other appropriate executive or committee.
No system requirements were identified.
1.33.3 Obtaining and Verifying Data: Obtaining and verifying the required credentialing information [e.g., using credential verification organization or other external
sources; obtaining DEA (Drug Enforcement Agency) certification with expiration, current malpractice insurance, response from National Practitioner Data Bank,
lawsuits, and from the State].
1.33.3.1 The system shall support the credentialing of individual clinicians (internal and
D
external providers).
1.33.3.2 The system shall support the certification of provider facilities. D
1.33.3.3 The system shall capture and maintain identification numbers and effective dates for
provider license, Drug Enforcement Administration (DEA) number, professional HD
liability insurance, etc.
1.33.3.4 The system shall capture and track NPI information (organizational provider, service
HD
facility, individual).
1.33.4 Communicating Result to Applicant: After reviewing all collected information, notifying the applicant clinician of the credentialing decision.
1.33.4.1 The system shall automatically generate expiration letters to providers (e.g., expiration
of licensure, Drug Enforcement Administration (DEA) number, professional liability HD
insurance) according to user-defined number of days prior to expiration date.
1.33.5 Maintaining Credential Data: Credentialing information is stored and periodically updated in the system.
1.33.5.1 The system shall track identification numbers and effective dates for provider license,
HD
Drug Enforcement Administration (DEA) number, professional liability insurance, etc.
1.33.5.2 The system shall automatically notify staff of providers who have not been re-
HD
credentialed by required date.

Appendix C - Functional Requirements (PS-1034) Page 104 of 110
Functional Requirements
1.33 Credentials License
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.33.5.3 The system shall automatically prompt to verify providers are re-credentialed by the
HD
required date.
1.33.5.4 The system shall support Federal and State requirements related to professional and
D
industry-specific licensing and credentialing.
1.33.5.5 The system shall provide the capability to track staff qualifications, including
credentials, privileges, and licensure, and currency requirements for licensed/certified D
staff and contract providers.
1.33.5.6 The system shall provide the capability for an authorized user to review license,
credential, and privilege expiration dates for licensed/certified staff and contracted D

1.33.5.7 individuals. shall provide the capability for an authorized user to configure the time
The system
D
period prior to a specific expiration date when an alert is to be sent.
1.33.5.8 The system shall provide an alert to affected staff or contract provider when current
D
license and/or credentials approach expiration deadlines.

Appendix C - Functional Requirements (PS-1034) Page 105 of 110
Functional Requirements
1.38 PQI

Requirement How
Prior. Avail. Description
Met
1.38 Performance Quality Improvement (PQI): Monitoring processes that affect the quality of client/patient care processes and/or outcomes. PQI identifies areas that need
improvement, develops solutions to rectify deficiencies, optimizes resource utilization, and improves processes and outcomes. PQI efforts are integrated with staff training.
1.38.1 Collecting, Aggregating, and Analyzing Data: Supporting the systematic capture, analysis, and reporting of data used in process improvement, outcome
measurement, and trend analysis. Includes data captured in assessments, treatment plans, discharge summaries, and other areas of the electronic health record.
1.38.1.1 The system shall permit the creation of a variety of outcome measurement instruments. D
1.38.1.2 The system shall incorporate a variety of 3rd-party licensed instruments that have been
D
authorized for use.
1.38.1.3 The system shall support Locally-defined scoring protocols that can be used to
D
summarize outcome instrument data.
1.38.1.4 The system shall permit Clinical review of outcome score trends over time (e.g.,
D
through on-line queries).
1.38.1.5 The system shall capture Outcome data elements. HD
1.38.1.6 The system shall capture and track age group specific (e.g., adult, child, elder, family)
HD
Outcome data (e.g., beginning and ending Outcomes).
1.38.1.7 The system shall support data mining, data analysis, data validation, reporting, queries,
HD
and billing.
1.35.2 Generate Reports: Generate appropriate reports for internal and external reporting as needed and on a timely basis (via paper forms, on-line screen, etc).
No system requirements were identified specific to this process.
1.35.3 Presentation: Graphical presentation of results.
No system requirements were identified specific to this process.

Appendix C - Functional Requirements (PS-1034) Page 106 of 110
Functional Requirements
1.39 Comm Education Outreach

Requirement How
Prior. Avail. Description
Met
1.39 Community Education and Outreach: Community Education and Outreach involves initiating communication and contact with the public, and disseminating
information to the public, for the purpose of providing health education, health promotion/disease prevention, training and/or skill building, activities, health related screenings,
educationally-based early intervention, and awareness of community services and resources.
1.39.1 Prevention: Designed to produce optimal behavioral health outcomes in a cost-effective manner through various approaches (population-based, proactive, disease-
specific) in delivering the services. Preventative behavioral health places strong emphasis on new education measures, practitioners, common outpatient procedures,
and adherence to prescription drug regimens.
1.39.1.1 The system shall capture and track prevention, early intervention, and outreach HD
activities.
1.39.1.2 The system shall capture and track demographics (recipients, viewers, attendees)
HD
depending on activity.
1.39.1.3 The system shall capture and track non-demographics (e.g., brochures and materials at
HD
health care meetings, environmental campaigns, mass media).
1.39.1.4 The system shall permit but not require the maintaining of a roster associated with an
HD
activity.
1.35.2 Client Satisfaction Surveys: Generate client satisfaction survey letters with pre-printed address labels to random samples, user-defined populations, or all BHS
clients. Capture interview online when client comes in for follow-up and E-mail results back to appropriate department.
1.35.2.1 The system shall provide tools for conducting client/customer satisfaction surveys,
HD
both on-line and through hardcopy collection means.
1.35.3 Analysis: Capture trends, analyzes and disseminates results of client satisfaction surveys.
1.35.1 The system shall have robust analysis and reporting capability (e.g., comparing pre-
HD
and post-test data).
1.35.2 The system shall support the ability to chart outcome data (e.g., pre- post- data entry). HD
1.35.3 The system shall visually present data for analysis and reporting. HD

Appendix C - Functional Requirements (PS-1034) Page 107 of 110
Functional Requirements
1.11 Portal
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.11 Portal: Maintaining a website that offers a range of capabilities that support accessing Health Agency services or promoting a client's well-being, such as e-mail, chat
boards, search engines, and content (e.g., Network of Care, DA/S web site).
1.11.1 Client Application/ Enrollment): Enabling the public to register or apply for services online.
1.11.1.1 The system shall support online completion and submission of various forms, including
but not limited to application, enrollment, and registration forms and customer HD
satisfaction surveys.
1.11.1.2 The system shall automatically populate appropriate forms (e.g., intake assessment)
HD
from data entered online.
1.11.2 Client Appointments: Supports online requests by clients for an appointment with specific clinician(s).
1.11.2.1 The system shall permit active and prospective clients to request an appointment. HD
1.11.2.2 The system shall capture requests for various appointment types, including drug
testing, intake assessment, appointment with assigned counselor/therapist for active HD

1.11.2.3 clients, etc. shall support: online viewing of scheduled appointments by active clients.
The system D
1.11.2.4 The system shall enable active clients to request changes to, or cancellation of, one or
D
more previously scheduled appointments
1.11.3 Client Account Checking and Bill Payment: Client checking status of their account; making payments for services received.
1.11.3.1 The system shall support online bill payments by active clients. D
1.11.3.2 The system shall permit active clients to view the status of their account (e.g., balance). D
1.11.4 Communication: Active clients sending secure messages to their clinician.
1.11.4.1 The system shall support chat rooms and/or forums for active clients. D
1.11.4.2 The system shall enable an active client to send a secure message to their assigned
D
counselor or therapist.
1.11.5 Service Provider Data Submission: Health Agency, Community-Based Organizations, and Network Providers submitting State-mandated CSI, CalOMS and DATAR
data.
1.11.5.1 The system shall enable the exchange of data with service providers. HD
1.11.5.2 The system shall support financial reporting with service providers. HD
1.11.5.3 The system shall support the sharing of outcomes data among authorized users HD
1.11.5.4 The system shall support online viewing of lab results for contract physicians, other
D
contract service providers, and staff.
1.11.5.5 The system shall support online exchange of data with service providers for contract
D
physicians, other contract service providers, and staff.

Appendix C - Functional Requirements (PS-1034) Page 108 of 110
Functional Requirements
1.11 Portal
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.11.5.6 The system shall support online creation of service plans for contract physicians, other
D
contract service providers, and staff.
1.11.5.7 The system shall support financial reporting with service providers for contract
D
physicians, other contract service providers, and staff.
1.11.5.8 For Service providers and CBOs, the system shall permit: online entering and viewing
D
CalOMS data
1.11.5.9 For Service providers and CBOs, the system shall permit: online viewing a client's drug
D
test results
1.11.5.10 For Service providers and CBOs, the system shall permit: online sharing of outcome D
1.11.5.11 dataService providers and CBOs, the system shall permit: online submission of DATAR
For D
1.11.5.12 For Service providers and CBOs, the system shall permit: online access to client record D
1.11.5.13 For Service providers and CBOs, the system shall permit the online viewing of
D
laboratory results.
1.11.5.14 For Service providers and CBOs, the system shall permit: online monthly billing and
D
annual cost reports [need clarification]
1.11.6 Service Provider Treatment/Service Planning: Supports online completion of service plans.
1.11.6.1 The system shall permit the online creation of service plans by authorized clinicians for
D
clients on their caseload.
1.11.6.2 The system shall permit direct entry and submission of CalOMS data by authorized D
users.
1.11.6.3 The system shall permit direct entry and submission of DATAR data by authorized D
users.
1.11.6.4 The system shall permit direct entry and submission of CSI data by authorized users. HD
1.11.7 Drug Testing: Service provider and active clients accessing drug testing schedules and results, as appropriate.
1.11.7.1 The system shall permit authorized individuals to view drug test schedule via mobile D
1.11.7.2 The system shall permit authorized individuals (e.g., active clients, clinicians, network
D
providers, CBOs, etc.) to view lab test results.
1.11.8 Chart Access: Service provider and client accessing a client's chart, as appropriate.
1.11.8.1 The system shall provide authorized users access to authorized sections of a client's
HD
record.
1.11.9 Information and Education: Provides information, including downloadable documents, that may be of interest to the general public, active or prospective clients
(e.g., what to expect during an inpatient PHF stay).

Appendix C - Functional Requirements (PS-1034) Page 109 of 110
Functional Requirements
1.11 Portal
How Met: Select one of the following -- Std. for Standard, Mjr for Major, Min. for Minor, N/A for Not Available
Avail: For Std. ONLY select one of the following -- Prod. For In Production, Beta for In Beta, Dev. For In Development, N/A for Not Applicable

Requirement How
Prior. Avail. Description
Met
1.11.9.1 The system shall permit the posting of public information/ education for prospective
PHF, MHS, and D/AS clients (e.g., education and prevention, services, programs, D
locations, hours of operation, and contact information).
1.11.9.2 The system shall permit the posting of documents that may be downloaded in pdf
D
format (e.g., applications and satisfaction surveys).
1.11.9.3 The system shall support electronically sending/receiving referral packets. D

Appendix C - Functional Requirements (PS-1034) Page 110 of 110

Other docs by ale15912

Liability Underwriting Inspection Form

Views: 16 | Downloads: 0

University of California Berkeley SUPPLEMENTAL STANDARDS LIBRARY ASSISTANT SERIES 2002 These supplemental standards are guidelines for classifying Library Assistant positions at the University

Views: 257 | Downloads: 0