Migrate from Jiva to HighLevel

Jiva's care-plan hierarchy has no native HighLevel equivalent — data requires a custom object and manual relationship mapping

Jiva organizes clinical data in a nested hierarchy: Population → Member → Care Plan → Assessment → Authorization. HighLevel has no native care-plan object and no hierarchical parent-child relationship model between custom objects. We create a Care_Plan__c custom object linked to the contact, but the hierarchical ordering of care-plan goals and interventions collapses into text fields. If your Jiva care plans include conditional rules (e.g., 'if blood pressure > X, escalate to review'), those rules cannot be preserved in a custom object field — they must be rebuilt as HighLevel workflow triggers. We surface this limitation in the pre-migration mapping plan so your clinical team can prioritize which care-plan rules need manual reconstruction in HighLevel's workflow builder.

HIPAA BAA coverage requires HighLevel Enterprise — Standard and Pro tiers do not include it

Jiva is built for HIPAA-regulated healthcare environments and includes BAA coverage as standard. HighLevel's Enterprise tier ($497/month base, with Enterprise add-ons) is the only tier that includes a signed Business Associate Agreement and HIPAA compliance tooling. If your Jiva data includes protected health information (PHI) — which most Jiva instances do by definition — you must activate HighLevel Enterprise before importing data, or you must de-identify PHI before migration (removing patient names, DOBs, MRNs, and clinical notes from the exported dataset). FlitStack flags any PHI field in the Jiva export, but the decision to de-identify or upgrade to Enterprise is a customer-side compliance determination. We cannot make that call on your behalf.

Jiva's clinical workflow rules cannot be exported as automation definitions — they must be rebuilt in HighLevel's workflow builder

Jiva's care-plan workflow logic lives in ZeOmega's clinical-rules engine: assessment-stage progression triggers, authorization threshold alerts, care-coordinator reassignment rules, and escalation pathways. These are not stored as exportable automation definitions — they are application-level business logic that cannot be extracted via Jiva's administrative export. HighLevel's workflow builder uses a completely different trigger-action model (event-based triggers, time-delay actions, tag-applications, and SMS/email sends). There is no automated conversion path. We export a structured summary of your Jiva workflow definitions — including rule names, trigger conditions, and action sequences — as a rebuild reference document. Your HighLevel admin uses that document to manually reconstruct the automation logic in HighLevel's workflow builder. This is the single largest manual-effort item in a Jiva-to-HighLevel migration.

Jiva's API export requires Enterprise-tier access — CSV exports from lower tiers may truncate custom fields

Jiva's full API access (for programmatic extraction of care-plan, authorization, and encounter data) is available only on Enterprise-tier ZeOmega subscriptions. Lower tiers rely on the Jiva administrative interface's CSV export, which caps custom fields at a configurable threshold and may omit clinical fields that exceed the export column limit. Before migration, we audit your Jiva export to identify any truncated custom fields. If truncation is detected, we recommend requesting temporary Enterprise API access from ZeOmega for the migration window, or we extract the data in batches across multiple CSV exports. We surface any data at risk of truncation before the migration plan is finalized.

Jiva's population and cohort assignments require value-by-value mapping to HighLevel tags

Jiva's population assignment is a structured field on the member record. HighLevel has no cohort or population object — we map each Jiva population name to a HighLevel tag applied to all members in that group. This is a value-mapping exercise: each unique Jiva population name generates a corresponding HighLevel tag. If your Jiva setup uses nested populations (e.g., 'Diabetes Program → High Risk → Q3 Cohort'), those nested relationships collapse to a single tag string. We preserve the full hierarchy in the tag name (Diabetes_Program_High_Risk_Q3_Cohort) but acknowledge that filtering on nested cohorts in HighLevel requires using the tag string rather than a structured filter.