Practical guide
Planning and validating practice integrations
Evaluate the connection your team will actually use
An integration directory should help a practice understand what moves between systems, which account is involved and what the staff must do when the expected result does not arrive. A provider name alone does not answer those questions. Use this directory to identify the connection you need, then validate the exact workflow against your practice’s supplier relationships, payment arrangement, payer requirements and communication setup.
Jelo’s confirmed connections described here are VisionWeb for optical lab ordering, Stripe for payment processing, Taiga for insurance and payer services, and Sinch for messaging delivery. These connections serve different purposes. An order sent to a lab, a card payment, an insurance reimbursement and a patient message have different records, prerequisites and exception-handling responsibilities. Treat each as its own operating workflow during evaluation.
Before the demo, write one sentence for each required connection: “Our staff needs to send this information through this account and inspect this result.” Include the intended office and the person responsible. This makes the requirement concrete enough to test. It also helps distinguish a missing account prerequisite from a software limitation, which matters when deciding the next step and the realistic implementation sequence.
VisionWeb: start with the account and attached labs
Jelo’s VisionWeb integration launched in September 2026. The workflow connects the practice’s VisionWeb account and uses the supplier relationships and catalog options available for that account. The practical starting point is therefore the account your practice will use, together with the labs and ordering options it expects to access. Do not assume that a lab is connected simply because its name is familiar to the team.
Review the returned lab accounts and catalog information with the person who normally prepares optical orders. Ask that person to identify the intended supplier and the lens options needed for a representative order. If something is missing, record whether the issue concerns the account relationship, catalog availability or the required workflow. The implementation team can then address the actual dependency rather than responding to a vague report that the integration is incomplete.
Keep lab-account readiness on the opening or migration checklist. An EHR configuration session may be complete while a supplier relationship still needs attention. Those are separate milestones. For the detailed connection description, use the VisionWeb guide, then validate the specific account before relying on it for real orders.
VisionWeb: separate retail preparation from the lab response
An optical order involves information from several parts of the practice. Staff need the correct patient context, prescription, frame variant, lens configuration and measurements required for the intended order. They also need to understand the lab’s response. A retail order record and a lab submission are related, but one should not be used as a substitute for checking the other.
During a fictional demonstration, follow the preparation of one representative order and ask how staff inspect the submission result. Then add an ordinary exception, such as an unavailable catalog option or an incomplete required detail. The practice should know who corrects the problem and which record shows that the next step can proceed. The goal is to understand the supported workflow, not to submit a real customer order from a marketing session.
Document the responsibility for changes after the initial order is prepared. A patient’s requested change may affect the retail record, the lab instructions or both. The exact supported correction process should be demonstrated with the team and supplier arrangement you will use. Avoid assuming that changing one screen automatically updates every outside record. A clear handoff prevents an internal edit from being mistaken for a confirmed supplier response.
Stripe: distinguish onboarding from a completed collection
Jelo uses Stripe for payment processing. The practice completes the integrated payment account’s onboarding and verifies its readiness before collecting real payments. That setup is separate from entering an order or configuring the rest of the platform. Identify who owns the payment account setup and who can resolve a question about its status, especially when implementation involves more than one location.
Jelo’s processing rate is 3.5% plus $1.30 per transaction. The rate is separate from the platform subscription and from insurance services. Keep it in the commercial comparison as its own line. Payout schedules, supported collection methods, hardware and the treatment of refunds or disputes should be reviewed for the actual account; this directory does not infer those details from the processor’s name.
In a demo, ask to see how an integrated payment link relates to an order and how staff confirm the result. A pending link is not a completed collection. The practice should know which record answers whether the patient still owes money and which processor record answers whether the charge succeeded. The payment guide develops those distinctions with arithmetic examples and reconciliation questions.
Stripe: keep processor records and bank records connected
A bank deposit may represent activity from several transactions. The practice therefore needs a reconciliation process that compares its payment records with processor activity and the resulting payout. Stripe’s documentation provides a processor-side explanation of payout reconciliation. Your practice’s order records supply the patient and order context needed to understand the same activity internally.
Consider a fictional day with several completed patient payments and one unresolved collection. Staff should be able to explain which items are complete, which remain pending and which belong in a later payout review. The operating exercise is about matching stages and references. It does not establish a particular settlement speed or guarantee that a bank deposit will appear on the same date as an order payment.
Also test an external-terminal example if your practice intends to use one. Recording an external-card payment in Jelo documents a transaction handled elsewhere; it does not send a charge through the integrated processor. Staff must verify the original transaction and reconcile the record. Review the existing non-integrated processing provision in the terms as part of the commercial decision, rather than assuming every alternative arrangement has identical charges.
Taiga: identify insurance and payer responsibilities
Insurance and payer services are handled by Taiga. Jelo’s AI biller service costs 10% of insurance reimbursement, separately from the platform subscription. The AI biller launched in August 2026 and is available in beta. There are no usage caps during beta, with future caps planned, but the reimbursement-based fee continues to apply. Availability and pricing should be understood together.
Bring the exact payer list and required transactions to the implementation review. Include the providers and locations involved. A general statement that insurance services are available does not establish that every payer, network or transaction type is supported for your account. Enrollment requirements and the information the practice must supply should be confirmed before a particular connection becomes part of the operating plan.
A useful discussion also names the responsibilities on each side. Which information must the practice provide? Who reviews clinical documentation and code selection? How does the practice respond when something is incomplete? Who handles a question about an unresolved payer response? Write down the supported service scope and the next contact. Clear responsibilities help the practice use the service without confusing software assistance with a guarantee of coverage or payment.
Taiga: review an unresolved item as well as a normal example
A successful-looking claim example can show the broad sequence, but an unresolved item often reveals more about how a service will fit the practice. Use a de-identified or fictional scenario and ask how the team identifies the source of the issue, what information the practice needs to provide and how progress is communicated. Keep the discussion focused on the supported process rather than a promise that every problem will be resolved automatically.
Separate the stages of billing work. Preparing a claim, submitting it, receiving a payer response, receiving a remittance and recording payment are different events. A status at one stage should not be interpreted as evidence that a later stage has occurred. Ask the person who will review finances to explain how they would distinguish reimbursement from an adjustment or remaining patient responsibility in the actual records.
The AI biller page describes confirmed availability and pricing. The claim follow-up guide provides an operating checklist for assigning and reviewing unresolved work. Neither replaces current payer requirements or the practice’s responsibility for documentation and code selection. Use them to make the service discussion more specific and to identify the facts that still need an account-level answer.
Sinch: review the sending setup and the reply workflow
Jelo’s published messaging terms identify Sinch as the provider for SMS and MMS delivery. Actual sending depends on the practice’s provisioned number, registration, consent process and enabled configuration. A messaging feature should therefore be evaluated together with those prerequisites. The software screen and the sending arrangement need to be ready for the same intended use.
Describe the messages your practice wants to send before discussing automation. Appointment-related communication, recall outreach and responses to patient questions can involve different operating decisions. Identify who chooses the message, who reviews replies and how a patient’s preferences are recorded in the supported workflow. Confirm the applicable consent and messaging requirements with the responsible practice representative; this directory does not provide a legal determination for every message type.
For multiple offices, review the number and reply-handling arrangement explicitly. Do not assume that each office automatically has a separate number or independent configuration. A shared team may need a different operating process from teams that manage their own communications. Bring the office structure and staff roles to the demonstration so the supported setup can be tested against the way the practice actually works.
Sinch: make message outcomes useful to staff
A sent message, a delivery result and a patient reply answer different questions. The practice should decide what staff will review and which outcome requires a next action. A patient who replies with a scheduling question creates work for the team; a message being sent does not establish that the appointment was booked. Keep the communication record connected to the task it is meant to support.
Use a fictional example to review the supported message and reply experience. Ask who monitors the relevant conversation and how another authorized employee understands what remains to be done. If the practice uses outreach as part of recall, define when a contact attempt becomes a completed follow-up and when it remains unresolved. These are operating definitions the team should agree on before comparing results.
Avoid putting unnecessary sensitive information into a routine message or public marketing example. Use the practice’s approved communication procedures and the current messaging consent information. The recall operations guide explains how to organize cohorts, follow-up ownership and measurement without treating a delivery count as evidence of patient attendance or a clinical outcome.
Ask specific questions about devices and prescribing
This directory does not establish a supported connection for every instrument, prescribing network or outside system a practice might use. List the exact device model, software version or transaction requirement that matters to your workflow. Ask what information can move, in which direction and through which supported setup. The word “integration” can describe very different levels of connection, so the expected result needs to be explicit.
For a device requirement, a useful question is whether the intended result can be demonstrated using the actual model or a documented supported configuration. For a prescribing requirement, review the intended service and any enrollment or identity prerequisites with the appropriate team. Do not treat the presence of a product category on a website as proof of account-specific readiness or coverage for a particular network.
Record unknowns as unknowns. A requirement may be supported, require setup, need further confirmation or fall outside the demonstrated scope. Those outcomes lead to different decisions. The vendor evaluation worksheet gives the practice a place to record evidence and follow-up without converting an unanswered question into an assumed feature.
Create an integration acceptance record
An acceptance record should identify the connection, account, office, task and expected result. Add the person who performed or observed the test and the date of the demonstration. If a prerequisite remains incomplete, name its owner and the evidence needed to close it. This makes the record useful after the meeting, when another employee needs to understand why a connection is or is not ready.
For each connection, include one normal example and one exception. A normal example shows the intended path. An exception shows how staff recognize an incomplete or unexpected result and where responsibility moves next. The practice should not have to infer the exception process from a successful screenshot. Use fictional or de-identified examples in demonstrations and the approved testing process for any account-specific validation.
Review the record with the people who will operate the connection. An owner may approve the purchase, but an optician, front-desk employee or billing reviewer may encounter the daily problem. Their questions often make the acceptance criteria more concrete. Keep the final record in the practice’s approved workspace and revisit it when the account, supplier relationship or operating requirement changes.
Plan account changes and interruptions
Connections depend on accounts and outside services that can change over time. Decide who maintains the account details and who communicates a change to the affected staff. A new lab relationship, a payment-account question or a messaging configuration change should have a named owner. This is especially important when the person who completed the original onboarding no longer holds the same responsibility.
Prepare an operating response for a connection that is temporarily unavailable or produces an unexpected result. Identify the work that should pause, the information staff should preserve and the contact who can investigate. This guide does not promise a universal offline mode or automatic recovery for every integration. The practice should review the supported behavior and agree on an appropriate temporary process for the specific dependency.
When service resumes, reconcile the unresolved work deliberately. Check whether an attempted action completed before repeating it, particularly for financial or order-related activity. The purpose is to avoid treating uncertainty as proof of failure. A clear status check and an identified owner make recovery more reliable than a collection of repeated attempts whose outcomes are difficult to distinguish.
Keep the commercial and security review alongside the workflow
Jelo’s platform is $300 per month per location or $3,000 per year per location, with unlimited doctors and staff at each paid location. Stripe processing and Taiga insurance services have the separate rates described above. Other account, supplier, hardware or service requirements should be reviewed in the applicable agreements. A complete cost comparison names the service being purchased and the assumptions behind any estimate.
Jelo is HIPAA compliant, offers a BAA and maintains BAAs with its providers. Its database is encrypted and backed up automatically every day. Practices with more detailed questions about data location, access, recovery or export scope should request those answers as part of the review. An integration relationship is not, by itself, an independent certification or endorsement of every workflow.
Joel or Loreli can lead a demonstration around your required connections. Bring the account and workflow list, the staff roles and the commercial questions. Leave with demonstrated scope, prerequisites and next actions recorded. That is the useful purpose of an integration directory: helping the practice move from a provider name to a connection it understands and can operate.