Evaluate an Article 31 clinic EHR with practical tests for MHOTRS documentation, billing, satellites, implementation, and vendor scope.
An Article 31 EHR evaluation should trace one clinic encounter from access and assessment through documentation, claim preparation, and reporting. A polished progress-note screen is useful, but it cannot show whether a New York outpatient clinic can run its entire day without losing responsibility at a handoff.
Start with the clinic's operating model. An adult program, a children's program with school satellites, and an organization operating several service lines may all describe themselves as Article 31 clinics while presenting very different purchasing problems. This guide offers an operational evaluation method. It does not establish licensure, coverage, or payment eligibility.
Article 31 EHR selection starts with program scope
The New York OMH MHOTRS program reference identifies its audience as licensed Article 31 MHOTRS programs. Use that program vocabulary in procurement rather than relying on a vendor's generic description of outpatient mental health.
Create a one-page scope sheet before requesting proposals. List the operating certificate, primary and satellite locations, population served, services actually delivered, payer mix, staffing roles, and reporting owners. Separate present operations from planned expansion. If a satellite is proposed but not yet approved, label it as proposed rather than letting the software project imply authorization to operate.
Attach the scope sheet to every vendor invitation. Otherwise each bidder can demonstrate a different interpretation of the clinic, and the selection committee ends up comparing presentations instead of comparable evidence.
Build a complete fictional encounter
Choose a representative patient journey without using real patient information. For example, an adult requests an appointment at a satellite, completes an assessment, receives an updated treatment plan, attends a session, and has an encounter sent to billing review. Give the evaluator the same fictional names, dates, insurance information, and staff roles for every demonstration.
Ask the presenter to show where each item originates and who can change it. If a service location is chosen during scheduling, verify whether the clinician and biller see that same location later. If a signed note is amended, ask how the amendment appears to the next reviewer. Record actual observations rather than accepting a statement that the product is configurable.
Include one exception. A canceled appointment, a staff reassignment, or an unsigned note is enough to reveal whether the workflow depends on a hidden spreadsheet. The goal is to discover where work waits and who can see it waiting.
Inspect the clinical record as a connected story
The OMH MHOTRS programmatic guidance addresses case records, assessment, and treatment planning in separate sections. Use those sections as the clinic's reference points, then ask the clinical lead to define how the organization's own documentation policies translate into a record review.
During the demonstration, follow an identified need from assessment into a treatment goal and then into an intervention documented in the encounter. Ask how a reviewer distinguishes a historical plan from the plan relevant to that service date. Test a correction after signature without pretending the original entry never existed.
Avoid judging quality by the number of fields on screen. A long form can still fail to capture the patient's response, while a shorter form may work well when supported by clear clinical policies and supervision. Ask staff to explain the record back in their own words.
Give billing its own acceptance test
An encounter that looks complete clinically can still need billing work. Have the billing lead identify the information needed to prepare the clinic's actual claims. Test coverage changes, a different rendering professional, an incorrect service location, and a note that is not ready for billing.
Keep benefit verification, authorization, coding, claim submission, and payment reconciliation as separate checkpoints. A successful action at one checkpoint does not prove success at the others. Ask the vendor to show the source of each billing field and what happens if the source changes after a draft charge exists.
For every automated step, ask for the exception queue. Who sees an error? Can the clinic identify an encounter that has not reached billing? Can staff distinguish a submission acknowledgment from adjudication? These questions matter more than a broad promise of revenue automation.
Score evidence and dependencies separately
Use a worksheet with columns for the requirement, scenario, observed result, evidence link, dependency, owner, and acceptance decision. Keep commercial preference separate from implementation risk. A strong demonstration may still rely on a costly integration or a configuration project the clinic has not staffed.
| Evidence status | What the committee records |
|---|---|
| Demonstrated | Completed during the agreed scenario, with a retained artifact |
| Configuration needed | Named work, owner, price treatment, and acceptance test |
| External dependency | Another system, agreement, or enrollment is involved |
| Manual process | Staff action remains part of the proposed workflow |
| Unverified | No acceptable demonstration or written evidence yet |
Do not convert an unverified item into a pass because the presenter says it is on the roadmap. Future functionality can be discussed commercially, but it is a different risk from a feature available for the proposed launch.
Test location and reporting assumptions
For a clinic with satellites, repeat part of the scenario at a second location. Inspect appointment assignment, the location on the clinical encounter, staff visibility, and the location reported to billing. A product may support multiple addresses while handling these dimensions differently.
Then ask for a small report whose rows can be checked manually. Select a date range and a clear definition, such as completed appointments for a named site. Reconcile the total to the fictional encounters. Change one appointment to canceled and rerun the report. This establishes what the report counts and avoids discovering after launch that different departments use different denominators.
Record the report filters and the date field used. Service date, signature date, charge date, and payment date answer different questions. The clinic should know which one each dashboard uses.
Turn the result into a purchasing decision
After the demonstration, conduct a short review with clinical, operations, billing, and IT representatives. Have each person identify the most serious unresolved workflow, not just their favorite feature. Assign evidence requests before discussing an overall ranking.
Ask shortlisted vendors to return a written scope tied to the test worksheet. Include configuration responsibilities, migration limits, dependencies, training, support arrangements, and the definition of acceptance. If a capability cannot be proven before contract, document the contractual treatment instead of leaving it as an informal expectation.
Ease Health is the publisher of this guide and sells behavioral health software. Organizations considering Ease can use the same evaluation script and ask the team to demonstrate the proposed configuration. Begin with the EHR overview, review the RCM overview, and bring the operational scope to an RFP discussion.
The useful output is a defensible evidence record: what was shown, what remains uncertain, what work the clinic owns, and what the vendor has committed to deliver. That record makes selection and implementation part of the same decision.
Related reading
Frequently Asked Questions
What should an Article 31 clinic ask an EHR vendor to demonstrate?
Ask for a complete encounter using a fictional clinic scenario, including the appointment, assessment, treatment plan, signed note, billing review, and a report that reconciles to the underlying records. Include a satellite scenario when relevant.
Does an EHR's feature list establish MHOTRS compliance?
No. A feature list does not establish how the clinic configures the system, how staff use it, or whether documentation and billing follow applicable New York guidance and payer terms. Evaluate those separately.
Should clinic billing staff participate in the EHR demo?
Yes. Billing staff can identify whether the demonstrated encounter contains the provider, location, coverage, service, and review information needed for the clinic's actual claim workflow.
How should a clinic record an unproven vendor capability?
Record it as unverified, with an owner and a deadline for evidence. Distinguish available functionality, configuration work, integrations, manual work, and future development in the written proposal.
