Changelog

How the VimOS versioning works

To provide application developers with the best user experience, allowing automatic bug fixes and easy access to new features while ensuring existing application code continues to work, VimOS offers a versioning system. This system works whether your application installs VimOS via npm or uses a script tag.

Bug fixes

Bug fixes are deployed to the latest version of the VimOS code. Since both the script tag and the npm package dynamically load the VimOS code, your application will automatically receive these fixes without any required changes on your part. Therefore, most bug fixes are not tied to a specific released version and will not be detailed on this page.

New features

Some non-breaking new features are added to the current latest version, while others will only be available in future versions. As mentioned above in the bug fixes section, your application will automatically gain access to new features added to the current latest version. However, if a feature includes new TypeScript types, upgrading the npm version will be required to take full advantage of it.

Consequently, the changelog for a specific version may be updated in the future if a new feature is released for it.

Breaking changes

Breaking changes will only be released in future versions. This ensures that as long as you don't upgrade the major version of the npm package you are using or change the URL of the script tag, your application will not break.

1.x.x (SDK) / 1.0.5 (npm) - November 14th, 2024

Add roles to user identifiers new feature

Added role information to user identifiers to enable role-based customization of the user experience. This enhancement provides more detailed user context and allows for dynamic interface adjustments based on user roles.

For further details, please refer to the updated documentation section here.

1.x.x (SDK) / 1.0.4 (npm) - September 25th, 2024

Add the ability to pass access token to initializeVimSDK function new feature

As part of the implementation of social login in the authentication flow implementation, you can now pass accessToken to the initializeVimSDK function.
This token is required for the SDK initialization to make authenticated requests to Vim's API

For further details, please refer to the updated documentation section here.

1.x.x (SDK) / 1.0.3 (npm) - September 16th, 2024

Add subscriptions for changes in updatable fields new feature

To enable your application to respond in real-time to changes in writeback capabilities, which ensures a seamless and responsive user experience, you can now subscribe to events that notify you whenever the availability of specific fields for writeback changes.

For further details, please refer to the updated documentation section here.

1.x.x (SDK) / 1.0.2 (npm) - August 25nd, 2024

Expose vimOS.sessionContext.getIdToken() method new feature

To enable optional Single Sign-On (SSO) functionality within your application, the vimOS.sessionContext.getIdToken() method has been exposed. This method allows your application to access the ID token, which is crucial for integrating with SSO flows.

For further details, please refer to the updated documentation section here.

1.x.x (SDK) / 1.0.1 (npm) - August 22nd, 2024

Make appTokenEndpoint parameter in SDK initialization options optional: The SDK will now use the token endpoint defined in the manifest if the parameter is not provided. new feature

Instead of the previously suggested initialization method, we recommend using the following approach that will derive the token endpoint from the manifest definition:

script tag

const vimOS = await window.vimSdk.initializeVimSDK();
// Use VimOS instance for further interactions with VimOS.js

npm

import { loadSdk } from 'vim-os-js-browser';

async function init() {
  const vimOS = await loadSdk();
  // Use vimOS instance for further interactions with VimOS.js
}
init();

1.x.x (SDK) / 1.0.0 (npm) - August 1st, 2024

Know why your application was open / closed new feature

We have upgraded the functionality of subscribing to changes in the app state. If you subscribe to appOpenStatus, whenever you application open status changes you will receive not only what the new status is, but also what triggered the change.

interface AppOpenStatus {
  isAppOpen: boolean;
  appOpenTrigger?: 'manually' | 'auto_popup' | 'push_notification_clicked';
  appCloseTrigger?: 'manually' | 'app_switch' | 'app_disabled';
};

Session context data reorganization breaking change

The Session context data is now organized under sub entities, with each sub entity connection to permissions to be set under app version manifest.

EHR resources reorganization breaking change

EHR resources, both for reading and for writebacks, are now organized under sub entities, with each sub entity connected to a permission to be set under app version manifest.

Replacement of Enum types with string type breaking change

We are moving away from using enums in our type system; Types that where defined as enums in pervious versions are now simple strings instead:

• The ActivationStatus in the setActivationStatus function.
• The ApplicationSize in the setDynamicAppSize function.
• The EHR resource types, such as when subscribing to ehr state changes
  • For example, if you were using vimOS.ehr.subscribe(EHR.EHRResource.patient, onPatientChange) to subscribe to patient changes, you should change it to vimOS.ehr.subscribe('patient', onPatientChange).
• The status and priority of a referral.
• The status of an encounter.
• The type of an order
• The buttonStyle in push notifications.