Migrate from Quanum Practice Management to HighLevel

Quanum sunset limits export window — data access has an expiration date

Quest Diagnostics placed Quanum Practice Solutions in read-only mode on January 1, 2024 and ended live subscriptions at contract cancellation. Delegated Admins must export CCDAs and Microsoft Access database dumps before the portal closes. FlitStack AI sequences the export phase first, extracting all patient records, encounter histories, and billing data from the Access database while the portal is still accessible. If the export window has already passed, we work with whatever export files exist and flag any records that were not captured before access was revoked. This is a hard deadline — unlike standard API migrations, there is no ongoing read access to pull from.

Appointment history creates one HighLevel activity record per visit — plan for volume

Quanum stores every appointment as a discrete record with its own date, provider, procedure code, and clinical note. A practice with five years of weekly visits for 500 patients generates roughly 130,000 encounter records. In HighLevel, each encounter maps to an individual activity (Task) with type, date, assigned user, and notes fields. The HighLevel API enforces a 200,000-request daily limit per sub-account, so we batch activity creation in pages of 1,000 records and throttle to stay under the limit. Activities beyond the migration window (e.g., appointments older than 24 months) can be optionally summarized into a single contact note per patient to reduce record count and API consumption.

No native billing engine in HighLevel — insurance and claims data need custom objects

HighLevel has no concept of claims submission, ERA processing, denial management, or revenue cycle reporting. Any insurance carrier data, group numbers, member IDs, guarantors, and outstanding balances from Quanum must be manually mapped to HighLevel custom fields and custom objects. We create a Guarantor custom object with relationship and contact-link fields, and a Billing_Record custom object with charge, payment, adjustment, and denial-code fields. These objects are not automatically included in HighLevel's standard reports — your team will need to build custom report types in HighLevel to surface billing data alongside contact records.

CCDA clinical documents attach as files — no field-level parsing without a middleware step

Quanum's Continuity of Care Documents contain structured clinical data (problems, medications, allergies, vitals) that could theoretically map to specific contact fields. However, CCDA parsing requires XML transformation logic that is outside the scope of a direct migration. We extract the CCDA, download it as a file, and attach it to the HighLevel contact record. For practices that need field-level clinical data surfaced in HighLevel (e.g., active medication list as a contact property), we offer an optional CCDA parsing pass as a separate service that extracts specific sections into custom fields after the initial migration completes.

Lab integration and e-prescription have no HighLevel equivalent — rebuild as workflows

Quanum's lab integration sent orders directly to Quest Diagnostics and received results back into the patient record. E-prescription transmitted prescriptions to pharmacies. HighLevel has no native lab order or e-prescription module. If your practice used these features, the workflow logic must be rebuilt using HighLevel's Workflow Builder with integrations to third-party lab and pharmacy services (e.g., Labcorp API, DoseSpot). We provide a feature-parity audit document that lists each Quanum integration and maps it to a recommended HighLevel workflow + third-party tool combination, but the actual automation build is outside the standard migration scope.