Changelog

​

October 2026

​

Added

• Upcoming change: with the next release, eligibility checks read like the payer’s portal and the request form follows each payer. The Results tab replaces Overview and Benefits: a member card with the plan network, every date and ID the payer sends about the member (such as a marketplace plan’s premium paid-to-date), the payer’s messages, customer service numbers and any other payer, provider information with the patient’s primary care provider, plan maximums and deductibles with individual and family side by side and what’s met and what remains (filter by network), CPT code answers, benefits by service with co-insurance, co-pay, benefit deductible, limitations and authorization, followed by the payer’s boxes such as Cost Containment and service level contacts, and Search for a service the payer only confirmed, contacts from the payer, additional information with the contacts the payer names for the whole plan, and the benefit disclaimer. It works on every past check. In the form, the payer comes first, then the provider and the patient; Search patient by lists the ways that payer finds a member and sends only the chosen option’s fields; CPT codes and a place of service appear only as the payer takes them, and switching payer removes what the new one doesn’t take, with a note. When a check fails, its page shows the payer’s message with the request under it, the rejected field marked and, when the payer has one, another way to search, so you can fix it and run it again in place. See Running an Eligibility Check.
• Upcoming change: with the next release, you can ask Solum to look at a completed verification of benefits (VOB) again. Request follow-up on the VOB’s page asks what Solum should look at again and posts your text as a comment. Until Solum closes the follow-up, the VOB shows a Follow-up pill and banner on its page and sits in a new Follow-up column on your board, and Mark as reviewed is unavailable. Solum’s reply arrives as a comment from Solum AI. When Solum re-checks the VOB with the payer or fixes the result, the VOB returns to Completed; when nothing changed, a VOB you had reviewed returns to Reviewed. Solum may also start a follow-up itself, and the VOB shows the same way. The VOB’s status stays completed throughout. In the API, POST /v1/verification-of-benefits/{id}/follow-up-request with {"content": "..."} (1 to 5000 characters) requests one and returns the VOB; it fails with 409 when the VOB isn’t completed, already has a follow-up open, has a newer VOB open on its policy or a newer VOB holding the policy’s current result, was imported before VOBs had their own page (backfilled: true), or its patient or policy was deleted, and with 403 for Solum’s global API keys. Every VOB returned by GET /v1/verification-of-benefits and GET /v1/verification-of-benefits/{id} carries follow_up (null unless Solum is following up: its state is requested while your request waits for someone at Solum to take it and in_progress once Solum is working on it, with requested_at and started_at). A single VOB’s responses, such as GET /v1/verification-of-benefits/{id}, also carry can_request_follow_up; list rows don’t. POST /v1/verification-of-benefits/{id}/review and POST /v1/verification-of-benefits/{id}/sync also fail with 409 while a follow-up is open: sync the VOB once Solum closes it. When Solum closes a follow-up after changing the result, the vob_updated webhook is sent with changed_fields: ["result"], and the corrected result is pushed again to the integrations that already received the VOB; a VOB you never synced isn’t pushed.
• Upcoming change: with the next release, you can mark a completed verification of benefits (VOB) as reviewed once you’ve dealt with it. Mark as reviewed on the VOB’s page, or in the table’s Reviewed column, takes it off your VOB board, which now hides reviewed VOBs by default; the new Hide reviewed / Only reviewed / Show all filter brings them back, a search for a patient finds them too, and Reopen undoes it. Reviewing never changes the VOB’s status. When the release goes live, VOBs completed more than 48 hours earlier start as reviewed. In the API, POST /v1/verification-of-benefits/{id}/review with {"reviewed": true} marks a completed VOB reviewed and false reopens it (409 when the VOB isn’t completed); every VOB returned by GET /v1/verification-of-benefits and GET /v1/verification-of-benefits/{id} carries clinic_reviewed_at and clinic_reviewed_by (null when it was marked through an API key), and the list accepts reviewed (true or false).
• Upcoming change: with the next release, a policy shows its latest eligibility check when the check is newer than Solum’s last verification: the payer’s answer, its date and a link to the check, on the patient’s Policies tab. When Solum hasn’t verified the policy yet, or the check disagrees with the last verification, the policy offers Request verification. A policy’s status still comes from Solum’s last completed verification. In the API, policies returned by GET /v1/patient-policies, GET /v1/patient-policies/{id} and expand[]=policies on the patient endpoints carry latest_eligibility_check (id, eligibility_status, created_at and payor_id, or null): the newest check whose answer (active or inactive) was written to the policy, by a match or by a VOB’s eligibility step. Its payor_id is the VOB result the check is linked to, if any: when it equals current_version.id, the current verification was built from that check. Eligibility checks carry patient_policy_id, the policy their answer was last written to. See After Matching.
• Upcoming API change: once the next backend release is promoted, the credentialing object on each specialty, in every verification of benefits the API returns and in POST /v1/verification-of-benefits/resolve, also carries the billing credential’s npi, tax_id, ptan, location (id, name, address, address_2, city, state, zip_code) and organization (id, name). Each reads the credential as it is now and is null when the credential has none; location is also null once the location was deactivated, and organization once it was deleted. The specialty’s own npi is still the one stored when the VOB was requested, so the two differ when the credential’s NPI was edited since.
• Rolling out: a prior authorization can request a verification of benefits (VOB) of its insurance with it once the prior authorization VOB release is enabled in your environment — check your environment’s API reference before integrating. POST /v1/prior-authorizations and PATCH /v1/prior-authorizations/{id} accept request_vob (boolean); omit it on a create to follow your company’s default, and a PATCH changes it in any status. A requested VOB covers the authorization’s services; the authorization’s insurance is saved on the patient when none of their policies matches it, and a VOB that cannot be requested never fails the authorization. POST /v1/prior-authorizations also accepts vob_specialties, the services the VOB verifies as POST /v1/verification-of-benefits takes them; omit it and the VOB covers the authorization’s own service, CPT codes and places of service, billed under its servicing provider (else its requesting provider). Prior authorization detail responses carry a vob block: state (requested, already_open, not_on_patient, missing_details or not_requested), a nested vob with the VOB’s id and status when there is one, and missing, which names what Solum still needs for the VOB. POST /v1/verification-of-benefits accepts prior_authorization_id to link a VOB to one of the patient’s prior authorizations on the policy’s insurance, and fails with 422 otherwise.
• Upcoming API change: once the backend release containing PR #1618 is promoted, a completed verification of benefits can be pushed to your integrations that sync VOBs. Every VOB returned by GET /v1/verification-of-benefits and GET /v1/verification-of-benefits/{id} carries sync: null while the VOB is not completed or when none of your integrations syncs VOBs, otherwise its status (not_synced until a push carries its results, then the latest push’s pending, success or failed) and attempted_at. One push carries the patient with all their results, so it covers every VOB completed before it. POST /v1/verification-of-benefits/{id}/sync pushes it: the push an integration that waits for your confirmation needs, or a resync for one that syncs when the patient’s last open VOB completes. It returns the VOB with its sync, and 409 when the VOB is not completed or none of your integrations syncs VOBs.
• Rolling out: a patient policy can hold the front and the back of the insurance card as files once the insurance card files release is enabled in your environment — check your environment’s API reference before integrating. Policies returned by GET /v1/patient-policies, GET /v1/patient-policies/{id} and expand[]=policies on the patient endpoints carry insurance_card_front_file_id and insurance_card_back_file_id (null until a card is attached), and POST /v1/patient-policies and PATCH /v1/patient-policies/{id} accept both; one file may fill both slots. A file must be the patient’s (or have no patient yet, in which case it is linked), active, and a PDF or an image, otherwise the request fails with 422 naming the field; deleting the file empties the slot. Two new document types, insurance_card_front and insurance_card_back, label the sides (insurance_card still means both sides, or a side that is not known), and Solum now classifies an uploaded card as a front, a back or both. POST /v1/files accepts an optional document_type, so an upload that already knows its label is not classified. The document_type filter on GET /v1/files is an exact match: insurance_card does not return insurance_card_front or insurance_card_back. See Insurance card.

​

Changed

• Upcoming change: with the next release, your verification of benefits (VOB) board shows one card per insurance policy: its open request, else its latest completed VOB. When you request a reverification, the new request takes the earlier VOB’s place, and the earlier card leaves Completed, Reviewed or Follow-up. A cancelled request never hides a result: when a policy’s newest request was cancelled, the board shows its latest completed VOB, and a policy whose requests were all cancelled shows the newest one. A patient search on the board finds each policy’s card; earlier VOBs stay in the table view and in the policy’s verifications on the patient’s Policies tab.
• Upcoming API change: with the next release, an API key reads a Solum staff member as Solum AI in a verification of benefits’ created_by (name is Solum AI, email and image are null), like every other actor field, such as clinic_reviewed_by and cancellation.cancelled_by.
• Upcoming change: with the next release, marking a completed verification of benefits (VOB) reviewed also sends it to your system when your integration waits for you to confirm each VOB. Mark as reviewed on the VOB’s page, or dragging its card to Reviewed on the board, sends the patient with the VOB’s results, as Sync does, to each such integration that doesn’t have them yet. A VOB a newer one replaced on its policy isn’t sent. Integrations that sync automatically when the patient’s last VOB completes aren’t sent anything again, and reopening a VOB doesn’t recall what was sent. Each completed VOB’s card on the board shows where its sync stands: synced, syncing, failed or not synced. In the API, POST /v1/verification-of-benefits/{id}/review with {"reviewed": true} starts that sync and returns the VOB with its sync.
• Upcoming change: with the next release, Solum writes a verification of benefits’ (VOB’s) AI summary when it completes the VOB, and again when it closes a follow-up that changed the result. While a VOB is open, its result’s ai_summary and ai_summary_generated_at stay as they are as Solum works the VOB. The new summary is written in the background, usually within 20 seconds: the vob_completed and vob_updated webhooks arrive before it, so read ai_summary on patient_verification_completed, which waits for the summaries of the patient’s verifications, or read the VOB again a little later. When Solum closes a follow-up after changing the result, the corrected result is pushed to your integrations once its new summary is written.
• Upcoming change: with the next release, your verification of benefits (VOB) board shows reviewed VOBs in their own Reviewed column, next to Completed, instead of hiding them. Drag a completed VOB’s card to Reviewed once you’ve dealt with it, or back to Completed to reopen it; the newest review comes first. The Hide reviewed / Only reviewed / Show all filter now belongs to the table. Anyone on your team can mark a VOB reviewed.
• Upcoming change: with the next release, the automatic eligibility check that starts every verification of benefits (VOB) asks the payer about the specialty’s CPT codes only when the payer answers per procedure. Most payers ignore CPT codes, and some reject a check that carries them or answer it as pending or inactive. When a check that asked about CPT codes doesn’t come back active, Solum asks again without them and writes that answer to the VOB. See Automatic Eligibility Checks.
• Upcoming API change: with the next release, POST /v1/patients/upsert reads a date_of_birth sent as eight digits in US order (MMDDYYYY, such as 04121985). Until now eight digits were read only as YYYYMMDD, and other eight-digit dates were dropped. When an upsert can’t create a patient, the 400 lists in dropped_fields a phone_number, email or date_of_birth Solum could not use (unreadable, or a date of birth outside 1900-01-01 to today), and its message names each one and what to send instead. See Required identifying info.
• Upcoming change: with the next release, each form sets the stage a patient moves to when its message sequence sends it to them. Workflow stage when sent sits in the form’s Settings tab under Workflow & Tags, next to Workflow stage when submitted (until now Workflow Stage by default). The Form default in Settings → Workflow Stages is removed, and every form linked to a sequence starts on the stage that default named. default_for is removed from the workflow stage endpoints (its last values were new_patient, intake_form and fax, which never set anything): stages no longer return it, and a request that sends it receives 422. See Workflow stages.
• Upcoming change: with the next release, the New Patient default in Settings → Workflow Stages is removed. A patient created from a prior authorization or by matching an eligibility check has no workflow stage: the Patients page lists it under Unassigned in the Table and A-Z views, and the Workflow board shows it once someone moves it to a stage. A patient a match creates also sends the patient_created webhook, as a patient created any other way does. See After Matching.
• Upcoming change: with the next release, the left menu starts with Dashboard, Verification of Benefits and Prior Authorizations, followed by Patients, Tasks, Insurance Monitoring, Eligibility Checks and Insurance Discovery. Insurance Monitoring opens your batches in one click instead of a hover menu, and Insurance Discovery has its own item. Signing in now opens Verification of Benefits instead of Patients. See Reviewing an Insurance Monitoring Batch.
• Upcoming change: with the next release, matching an eligibility check to a patient can request a verification of benefits (VOB). Check Request a VOB after matching, and once the match is saved the VOB request opens for the insurance you matched, so you can review its services before creating it. The box starts checked when Request a VOB after each eligibility match is on in Settings → Eligibility (off by default). The eligibility default workflow stage is removed, and the workflow stage endpoints’ default_for no longer takes eligibility. See Matching Results to a Patient.
• Upcoming API change: once the backend release containing PR #1612 is promoted, workflow_stage, when the patient endpoints expand it, carries sync_external (boolean) instead of actions. true means a patient who enters the stage is synced to the stage’s integration. The workflow stage endpoints (/v1/workflow/stages and /v1/workflow/stages/{id}) take and return sync_external the same way, with integration_id required when it is true; a request that sends actions receives 422.
• Upcoming API change: once the backend release containing PR #1618 is promoted, moving a patient between workflow stages no longer syncs them to an integration. sync_external and integration_id are removed from the workflow stage endpoints (/v1/workflow/stages and /v1/workflow/stages/{id}) and from workflow_stage when the patient endpoints expand it; a request that sends either receives 422. An integration now syncs a patient on events Solum sets up with you: when the patient’s last open VOB completes, when someone presses Sync on a completed VOB, when a VOB needs missing information, when the patient is created, or when a prior authorization is decided or needs information. On patient-list items, sync_status, sync_error_message and has_sync_completed describe the patient’s latest sync whatever their stage. The Sync item in the patient actions menu is removed.
• Upcoming change: with the next release, a prior authorization whose type doesn’t fit its ABA codes (a Treatment or Re-assessment & Treatment that requests only assessment codes such as 97151, or an Assessment or Reassessment that requests treatment codes such as 97153) shows a warning. On the request form, when you create from documents, and on the prior authorization’s page while the request can still be edited, the warning switches to the type the codes fit in one click; Duplicate warns that the copy keeps codes that won’t fit the type you pick. Solum also reads the type from uploaded documents more reliably: in ABA, a diagnosis, referral or evaluation that recommends therapy is read as an Assessment request, not Treatment; a physical, occupational or speech therapy order to evaluate and treat is read as Treatment. See Select Authorization Type.
• Upcoming change: once the backend release containing PR #1596 is promoted, a verification of benefits with no network status takes one from your credentialing when Solum writes an eligibility check into it: In network when the NPI it bills under is linked to the policy’s insurance as Active (or, with no link to the insurance, when the policy’s plan type is one of that NPI’s In-network with all plans of these types), Out of network when the link is Out Of Network. An insurance with no link and no matching plan type leaves the status empty, and a network status already on the VOB is never replaced. See Network Status on VOBs.
• Upcoming change: the Insurance Expirations dashboard and the expiration_filter parameter on GET /v1/patient-policies will be removed with the next release. After that release, unsupported query parameters receive 422 naming the parameter. Use end_date_gte and end_date_lte to filter policies by coverage end date. Insurance records, verification of benefits, and prior authorization expiration emails remain available.
• Upcoming API change: POST /v1/patients/batch and the Bulk Import (CSV) option under Add Patient will be removed with the next release. Requests to POST /v1/patients/batch will receive 405 after that release. To create or update patients from an integration, call POST /v1/patients/upsert once per patient.
• Upcoming change: Add Patient (Manual Entry and From File) will be removed from the Patients page with the next release. You create a new patient while you request their work: Create VOB under Verification of Benefits, or New Request under Prior Authorizations. After that release, Actions on the Patients page links to both. See Creating a Patient.
• Upcoming API change: with the same release, source_extraction_id on POST /v1/patients/upsert accepts completed fax extractions only. Any other extraction is rejected with 400 naming source_extraction_id.

​

September 2026

​

Added

• Every VOB returned by GET /v1/verification-of-benefits and GET /v1/verification-of-benefits/{id} now carries result_id: the id of its result, or null while it has none (including when its result was deleted). A list can tell the VOBs that have a result from those that don’t without include=result; a policy’s current verification is the result of its latest completed VOB that has one.

​

Changed

• Upcoming API change: the public POST /v1/voice-calls endpoint will be removed with the admin voice-call release. API-key integrations will receive 404 after that cutover; there is no compatibility alias. Voice-call creation and preview will be available only to authenticated staff through /v1/admin/voice-calls. Check your environment’s API reference before integrating. Automatic calls initiated by eligibility checks will continue.
• A patient’s coverages are now patient policies, with their own /v1/patient-policies endpoint. Patient create, update, upsert, and batch import now send coverages under policies — a request that still sends coverages under payors is rejected with an error naming policies. coverage_tier (formerly payor_responsibility) is now required on every new coverage, several fields were renamed (insured_member_id → member_number, coverage_from/coverage_to → start_date/end_date, plan_type → insurance_type, and a nested subscriber), and prior authorization requests reference a coverage with patient_policy_id/policy_data. Reads changed too: the patient’s payors field is now policies (requested with expand[]=policies instead of expand[]=payors), and the GET /v1/patients filter plan_types[] is now insurance_types[]. Patient endpoints now report per-coverage outcomes as policy_results, each with an action; a coverage field that cannot be stored (a display name that is not one of the insurance’s aliases, or a start date after the end date) is dropped and reported without failing the other coverages. An upsert that contradicts itself fails whole, before anything is written: two coverages on one tier or one external ID on two coverages (422), or a coverage external ID another patient’s coverage holds (409). A patient now holds one active coverage per insurance and member ID: sending the same coverage twice is rejected, and existing duplicates keep the higher tier. A coverage now matches an existing one only by its external ID, or by the same insurance and member ID; a different member ID on an insurance the patient already has is a new coverage, so send the coverage’s policy_id (new on upsert coverages) or its external ID to correct a member ID; when a reviewed document’s member ID differs from the patient’s coverage on that insurance, the review asks whether it updates that coverage or adds a new one. A coverage that matches by insurance and member ID but carries a different external ID than the existing one is rejected (409). A coverage that claims a coverage_tier another coverage holds now moves that coverage to the first free tier instead of deleting it; the move is reported as a moved result (insurance_moved_count in batch imports), and a request with no free tier left is rejected (409). Removing a coverage now deletes it outright, with no archive or reactivate, and only when you delete it. A coverage sent to a patient endpoint carries the coverage only: provider_network_status, plan_funding_type, eligibility_check_comment and services are no longer accepted there (a request that sends them is rejected with an error naming the field). Each verification of a coverage is a version, read through the VOB that produced it: list a policy’s VOBs with GET /v1/verification-of-benefits?patient_policy_id=...&include=result, or read one directly with GET /v1/verification-of-benefits/{id}. See the updated Upsert Patient guide for the current request and response shapes.
• VOB turnaround now pauses while a verification is waiting on missing information from you, so the time it takes to send the details no longer counts against the SLA shown in your dashboard
• Verifications of benefits are now requested and tracked per patient policy rather than per patient: each policy has at most one open VOB at a time, and its requested specialties (service type, credentialing, CPT codes, place of service) are resolved and stored explicitly on the request. /v1/payors and /v1/payor-services are removed — a coverage’s verification result is no longer written directly by your integration. The Solum team now writes and edits every VOB result; your integration and clinic users read it through GET /v1/verification-of-benefits/{id}, whose response carries the same benefits, services, and AI summary fields /v1/payors used to. The VOB resource itself keeps living at /v1/verification-of-benefits — the separate /v1/verification-of-benefits/requests and /v1/verification-of-benefits/completions paths some integrations used are gone; create, update, and read all go through the one resource path. A VOB’s request (its priority and specialties) can be edited while the VOB is pending or waiting for missing information. POST /v1/verification-of-benefits/resolve shows what a request would resolve to (each specialty’s billing credential, CPT codes, places of service and ICD codes, or the errors a create would return) without creating anything. POST /v1/voice-calls now targets a VOB directly with vob_request_id (replacing payor_id).

​

July 2026

​

Added

• Call Activity, for teams with calling enabled, see inbound and outbound call counts and appointments booked — each compared with the previous period — plus a call-duration breakdown, right on your dashboard

​

June 2026

​

Added

• Automatic Eligibility Checks, automatically verify a patient’s coverage when they enter an Insurance Verification stage, with benefits filled in on Active results
• Insurance Discovery, search for a patient’s active coverage when the payer or member ID is unknown
• Comments and Mentions, leave comments and @-mention teammates across patients, tasks, prior authorizations, and eligibility checks, with email notifications
• Prior Authorization Enhancements, reassessment types, appeal and reference numbers, appeal-status authorizations, and follow-up tracking
• Patient Locations, link patients to your company’s locations

​

Changed

• Eligibility service types are now chosen per payor (the payor’s own services, then the patient’s referral, then your company default) instead of one fixed default for every check

​

Fixed

• Member IDs containing spaces or punctuation no longer block automatic eligibility checks

​

May 2026

​

Added

• Prior Authorization Module, track prior authorizations end to end with servicing locations, CPT unit types, appeal availability, a status workflow, and filters
• Document Auto-Classification, every uploaded document is automatically classified by type
• Insurance Expirations Dashboard, see upcoming insurance plan and authorization expirations with filters and quick actions
• Multi-payer Create-from-File, capture secondary, tertiary, and quaternary payers when creating from a document

​

Changed

• Eligibility Matching, smarter prefills, conflict recovery, and payers grouped by your company insurances
• Tasks with unread comments now float to the top of the list

​

Fixed

• Default Medicare Part B physical therapy coinsurance when the payer omits it

​

April 2026

​

Added

• Eligibility Check PDFs, download a formatted PDF of any eligibility check, including an AI-generated benefits summary
• Faxes Dashboard Match Breakdown, see auto, linked, and manual match counts at a glance

​

Changed

• Form submissions split into capture and reconcile phases with improved fuzzy patient matching
• Inline editing and copy-to-clipboard across patient information cards

​

Fixed

• Member ID validation before submitting eligibility requests
• Improved messaging sequence scheduling reliability

​

March 2026

​

Changed

• Messaging Sequences v2, refreshed automated messaging sequences
• Expanded CRM integration syncing for patient and contact data

​

February 2026

​

Added

• Fax V2, redesigned fax system with improved reliability, faster processing, and an enhanced user experience

​

December 2025

​

Added

• Direct File Uploads, files now upload directly to secure cloud storage for faster and more reliable form submissions
• Internal VOB Queue, new internal queue system for managing verification of benefits requests more efficiently

​

Security

• Updated security dependencies to address vulnerabilities

​

November 2025

​

Added

• Therapist Management, new module to add, edit, and manage therapists with location assignments
• Telehealth Support, added telehealth service options and location based rate configurations
• VOB Enhancements, improved verification of benefits workflow with better status tracking
• Fax Automation, automated fax processing with AI powered document classification
• Group Numbers, support for insurance group numbers in patient records
• Error Monitoring, integrated Sentry for proactive error detection and faster issue resolution

​

Fixed

• Improved dashboard performance and data accuracy
• Resolved issues with intake form submissions

​

October 2025

​

Added

• Scheduled Messages, schedule text messages to patients for future delivery
• Batch Processing, process multiple patient records simultaneously
• Conditional Form Fields, show or hide form fields based on previous answers
• Website Assistant, new AI assistant type for website chat integration
• Knowledge Base, upload documents to train your AI assistants with custom knowledge
• Assistant Configuration, customize AI assistant behavior and responses

​

Fixed

• Resolved timeout issues during large data exports

​

September 2025

​

Added

• Unread Message Indicator, see unread message counts directly in the sidebar
• Task Workflow Filters, filter tasks by workflow stage for better organization
• Multi language Intake Forms, intake forms now support Spanish translations
• Enhanced Fax Processing, redesigned fax review interface with better patient matching
• Improved Task Management, new task interface with better status tracking and assignments
• Activity Timeline, view complete patient activity history in one place

​

Fixed

• Multiple improvements to fax processing accuracy
• Better error messages throughout the application

​

August 2025

​

Added

• Integrations Hub, new centralized page to manage all your third party integrations
• Forms Builder, create custom intake forms with drag and drop fields
• Session Tracking, view and manage patient web sessions
• AI Conversations (Beta), new AI powered conversation interface for patient communication
• Call Evaluation Metrics, track and analyze AI call performance
• Intake Form Feedback, collect patient feedback after form completion
• Advanced Patient Filters, filter patients by date range, insurance, and custom tags

​

Fixed

• Improved intake form reliability and validation

​

July 2025

​

Added

• Multiple Service Types, assign multiple service types to a single patient for comprehensive care tracking
• KPI Dashboard Updates, new Appointments Booked metric added to dashboard
• Enhanced Insurance Handling, better support for coordination of benefits (COB) status

​

Changed

• Performance Improvements, major backend optimization for faster page loads and API responses
• Improved data consistency across all modules

​

Fixed

• Resolved issues with patient creation workflow
• Fixed fax processing errors for certain document types

​

April 4, 2025

​

Platform Integrations and Features

​

Added

• New Status Page: Monitor our system’s health and performance in real-time at status.getsolum.com
• Zoho Integration: Enhanced business operations with seamless Zoho integration
• HubSpot Integration: New CRM capabilities through HubSpot integration
• Cal.com Integration: AI agents can now directly schedule appointments and check availability through Cal.com integration
• EHR Sync Function: New feature to synchronize patient data with your EHR system
  • Automatic field validation and missing information alerts
  • Direct synchronization from Solum platform
  • Smart field mapping and verification

​

How to Read the Changelog

Each changelog entry includes:

• The date of the changes
• A description of what was changed
• The type of change (Added, Changed, Fixed, Deprecated, Removed, Security)
• Any relevant links or additional information

To stay updated with our latest changes:

• Bookmark this page
• Follow us on LinkedIn
• Check our Blog for detailed announcements