Complete guide to migrate from Suki.js v1 to v2 with enhanced provider onboarding, LOINC standardization, and improved UI customization.
The v2.0.0 release of Suki.js includes significant improvements that enhance clinical documentation workflows and standardize healthcare integrations. This guide will walk you through the migration process step by step.
The v2.0.0 release introduces several key improvements:
This is a breaking change release. Please review all changes carefully before upgrading.
Begin by updating to the latest version of the Suki SDK:
The initialization process now requires additional provider information for automatic onboarding.
providerName (Required)
The full name of the healthcare provider using the SDK, including first name, middle name (if applicable), and last name separated by spaces.
This information enables automatic provider onboarding in the Suki system without manual registration.
Example: "Dr. Jane Marie Smith"
providerOrgId (Required)
The unique identifier of the healthcare organization to which the provider belongs in your system.
This ID facilitates automatic organizational mapping and ensures proper data segregation in the Suki platform. This should match the organization ID in your system’s database for consistency across platforms.
Example: "northwell-1234"
or "memorial-hermann-5678"
providerSpecialty (Optional)
The medical specialty of the provider, which helps tailor the SDK’s functionality to specific clinical contexts.
If omitted, the system defaults to "FAMILY_MEDICINE"
as the provider specialty. This information improves the relevance of automated suggestions and templates during onboarding.
Refer to the Specialties documentation for a comprehensive list of supported specialties.
The ambient options structure has been completely redesigned to use standardized LOINC codes instead of custom note type IDs.
The prefill.noteTypeIds
approach is still supported but deprecated and will be removed in future versions. We strongly recommend migrating to the new section-based configuration using LOINC codes.
Refer to the Note Sections documentation for a complete list of supported sections and corresponding LOINC codes.
The uiOptions
property now provides more granular control over the SDK’s user interface elements.
Field | Description | Default | Type | Required |
---|---|---|---|---|
showCloseButton | Controls visibility of the close button in the header | false | Boolean | No |
showCreateEmptyNoteButton | Controls visibility of the “Create Empty Note” button on the patient profile | false | Boolean | No |
showStartAmbientButton | Controls visibility of the “Start Ambient” button for ambient mode initiation | true | Boolean | No |
sectionEditing.enableDictation | Controls the microphone icon for voice input (activates voice-to-text feature) | false | Boolean | No |
sectionEditing.enableCopy | Controls the copy icon for text copying functionality | false | Boolean | No |
You should only provide explicit values when you need to enable specific features. For example:
The note submission payload now includes LOINC codes for better standardization.
Refer to NoteContent for the complete structure of the note content.
Here’s a complete example showing the migration from v1.x to v2.0:
Required Provider Information
providerName
and providerOrgId
are now required fields in initializationAmbientOptions Structure
prefill.noteTypeIds
to a section-based configuration using LOINC codesTheme Property Names
primaryColor
renamed to primary
background
, secondaryBackground
, foreground
, and warning
Required Mount Options
ambientOptions
is now required when mounting the SDK (was optional in v1.x)Initialization Errors
missing-partner-details
: Provider information is incompleteno-partner-token
: Authentication token is missingno-init
: SDK not properly initializedAmbient Mode Errors
no-ambient
: Ambient mode not availableambient-in-progress
: Another ambient session is activealready-started
: Ambient session already runningLOINC Code Errors
unsupported-loinc-codes
: One or more LOINC codes are not supportedno-supported-loinc-codes
: No valid LOINC codes providedAfter migration, verify the following:
Learn about supported LOINC codes and section configurations
View the complete list of supported medical specialties
Implement proper error handling for your integration
See complete examples of the v2.0 implementation