Updated: mSupply Version 4.12
mSupply's remote synchronisation allows mSupply running stores on local servers to send data to a central mSupply server for combined reporting.
In a mirrored synchronisation system, the primary server becomes a remote site with responsibility for editing the central data:
The typical use case is where a site in a country that has the responsibility for administering items has poor internet (typically the Central Medical Stores), so that it either can't run the central server locally and/or can't reliably connect to a cloud-based central server. By using mirrored sync, this site retains authority, but a reliable central server elsewhere ensures that synchronisation with other sites is not hindered and that external users can still access the dashboard.
Stores to be synced will exist as separate instances of the same store on more than one sync site:
On a mirrored sync system, the store must be created first on the primary server. It will then sync to the central server, where the store's site can then be assigned and its sync preferences configured.
Synchronisation type drop down list: Shows the sync type of the current store. Will be editable on the central server if you have unlocked it using the Click to unlock button.
Click to unlock button: Click it to enter the unlocking password to enable you to edit the settings on this tab.
Set as local store checkbox: Will be editable on the central server if you have unlocked it using the Click to unlock button. If checked, this will change the store's Sync ID to be that of the current site and will uncheck any of the elements in the Local column in the Sync with table.
Include transactions in sync checkbox: Only affects dispensary stores, as transactions are always synced otherwise. If checked for a dispensary store, this will also sync prescriptions and related dispensary data. This preference is turned on by default for all stores and is permanently disabled (regardless of whether you have unlocked the settings using the Unlock button). It can only be turned off by Sustainable Solutions.
Resync patient records when store is saved checkbox: If checked, when you click the OK button to save the store's settings, the central server will resend all the patient records for patients visible in the store to the active copy of the store. Along with that, all the other dispensary related information that is required will be sent, such as patient medication records, prescribers, abbreviations, insurance providers, directions, prescription categories and diagnoses. Quite a lot of information
Sync ID field: Displays the sync ID of the current store so that you can see which one in the table below you're talking about! The store's sync ID should almost always be the ID of the site where the store is active.
Sync with table: Shows the other sites in your sync setup that the current store will sync with. Also defines what relationship those other store instances have to your current one and therefore what records need to be sent to that site from the instance of the current store on the current site. Will be editable (only on the central server) if you have entered the password using the Click to unlock button. Checking any checkbox in the Local column will set the store's Sync ID to be that of the selected row, and will uncheck any others as well as the Set as local store checkbox.
This setting is a bit confusing, but it does work to understand it as 'whatever the sync type of the store is on that site'.
If your version of mSupply server is pre 3.50, after changing sync settings for a store you will have to restart the mSupply application on the primary server for the changes to be applied.
These settings are necessarily complex and should only be modified by Sustainable Solutions, after discussions to agree on the configuration which is the best fit for requirements.
Each store in a synchronised system needs to have a sync “type” as described here.
A store whose sync type is active means that the store-specific data can be edited (added, edited, deleted) on the sync site where you are logged into this store.
A store whose sync type is collector means that the store-specific data can not be edited on this sync site. The store on this server receives all store data from an active store on another sync site i.e. it is a replica of a corresponding active store on another sync site. This means that the store can be examined and reports generated on this sync site.
A store whose sync type is transfer is similar to the collector type except that the store on this sync site is used only as a vehicle for receiving stock transfers or requisitions from other stores on the same sync site and passing them on to the corresponding store on other sync sites. It doesn't receive any other store data (such as stock lines). That is, it is not a replica of an active store, and should not be used as such. The store can not be examined or have reports generated on this sync site. The benefit of a transfer store over a collector store is that transfer stores require less data to be synced between servers.
Updated: mSupply Version 4.12
The Store 'sync-with' options control which store-specific synchronisation data gets sent to the other sync sites which are linked to that sync site:
A value of None means that this store doesn't sync with the corresponding store on the selected sync site. That is, there is no instance of this store on that sync site. If a store is not visible to any stores active on the selected sync site, or its visibility settings are changed so that it becomes invisible to all active stores on the selected sync site, then it will automatically be set to None for that site.
A value of Active/collector means that store-specific data edits, including any edits to the core store data, are synced to the corresponding store instance on the selected sync site. The store instance on the selected sync site will normally be of type active (on the site with matching sync ID) or collector (on any other sites). A store cannot be a collector on the selected sync site unless it is visible to at least one other store which is active on the site.
A value of Transfer means that any updates to the core store data, or any stock transfers or requisitions into that store, are synced to the corresponding store instance on the selected sync site. No other transactions or other store-specific data will be transferred. The store instance on the selected sync site will normally be of type transfer. If a store's visibility settings are changed so that it becomes visible to any other stores which are active on the selected sync site, then it will automatically be set to Transfer for that site.
An example of a store on the sync server which needs to also be reportable on another remote site.
Store A exists as an Active store on sync server and as a Collector store on remote site 1:
An example of a store on one remote site which needs to receive stock transfers from a store on another remote site.
Store B exists as a Collector store on sync server, an Active store on remote site 1, and a Transfer store on remote site 2:
Another example of a store on one remote site which needs to receive stock transfers from a store on another remote site.
Store C exists as a Collector store on sync server, an Active store on remote site 2, and a Transfer store on remote site 1:
An example of a store on a remote site which needs to also be reportable on the sync server.
Store D exists as an Active store on remote site 2 and as a Collector store on sync server:
An example of a store which is local to the sync server only.
Store E exists only on sync server (and primary server, if different):
An example of a store which is local to a single remote site.
Store F exists on remote site 1, but it must also exist on the sync server (and primary server, if different) as a Transfer store, so that it can be centrally managed:
The table below is a high-level summary of the different data types:
Data | 'Normal' Sync | If using Mirror Sync | Notes |
---|---|---|---|
Items | Central | Primary | Including item-related data e.g. item categories, units, BOM masters |
Names (except patients) | Central | Primary | Including name-related data e.g. name categories, contacts, tags |
Merging of items, units and names (except patients) | Central | Primary | |
Groups and departments | Central | Primary | |
Item master lists and programmes | Central | Primary | |
Budgets, periods and accounts | Central | Primary | |
Transaction categories and payment types | Central | Primary | |
Purchase order categories | Central | Primary | |
Custom data | Central | Primary | |
Barcodes | Central | Primary | |
Currencies | Central | Primary | |
Options and properties | Central | Primary | |
Location types | Central | Primary | |
Regimens and indicators | Central | Primary | |
Drug interactions and warnings | Central | Primary | |
Vaccinators and vaccine settings | Central | Primary | |
Custom reports | Central | Primary | Standard reports are regenerated on each upgrade |
Asset settings | Central | Primary | |
Regions | Central | Primary | |
Incoterms and tender conditions | Central | Primary | |
Abbreviations and item directions | Central | Primary | Dispensary data |
Diagnoses | Central | Primary | Dispensary data |
Insurance providers | Central | Primary | Dispensary data |
Patient event types | Central | Primary | Dispensary data |
Stores and non sync-related store preferences | Central store | Primary | |
Purchase orders (centralised) | Central store | Primary | |
Tenders and quotes (centralised) | Central store | Primary | |
Payments (centralised) | Central store | Primary | |
Visibility of items and names (except patients) | Central store | Primary | |
Visibility of existing patients and prescribers | Central store | Primary | |
Sites and sync-related preferences | Sync | Central | Changes on the central server indirectly update related records on remote sites |
Dashboard reports | Sync | Central | |
Messages | Message | Store | Depends on sending and/or receiving store (which can be blank) |
Visibility of new patients and prescribers | Patient | Store | New visibility records sent to central server |
Patients and prescribers | Patient | Store | Including patient-related data e.g. PMR, insurance policies |
Merging of patients and prescribers | Patient | Store | |
Patient events | Patient | Store | Dispensary data |
Repeats | Patient | Store | Dispensary data; preference can be set to allow processing on all sites where the patient is visible |
Prescriptions | Patient | Store | Preference can be set sync to all sites where the patient is visible |
Name notes | Store | Store | |
Customer stock history and requisitions | Store | Store | |
Locations | Store | Store | |
Merging locations | Store | Store | |
Stock and replenishments | Store | Store | |
Stocktakes and inventory adjustments | Store | Store | |
AMC projections | Store | Store | |
Transactions (but not prescriptions) | Store | Store | Including other transaction-related data e.g. backorders, builds |
Transaction notes | Store | Store | |
Item notes | Store | Store | |
Boxes | Store | Store | |
Goods received | Store | Store | |
Indicator values | Store | Store | |
Vaccine monitors/sensors | Store | Store | |
Assets | Store | Store | |
Store credentials | Store | Store | |
Authorisers and authorisation | Store | Store | |
Tenders and quotes | Store | Store | Except for centralised procurement |
Purchase orders | Store | Store | Except for centralised procurement or supervisor-mode ordering |
Payments | Store | Store | Except for centralised payments |
New users | Store | Store | New user records sent to central server |
User licenses and existing users | Local | Local | |
User permissions | Local | Local | |
Preferences (non-store) | Local | Local | Except for a few special cases which are explicitly synced |
Reference documents | Local | Local | |
HIS | Local | Local | |
Drug registration | Local | Local | |
Labels | Local | Local | |
Logs | Local | Local | |
Reminders | Local | Local | |
Adverse drug reactions | Local | Local |
These are a special case:
If this preference is switched on in the primary site, then purchase orders can be entered for any store on the primary, regardless of its sync type (i.e. not just for active stores).
If it is switched on in a satellite, then purchase orders cannot be entered for any store on the satellite, even if it is active.
When this preference is changed on the primary, the change will propagate to all the satellites as well.
It is still possible to edit the preference on the remote (e.g. to allow local procurement for stores active on that site), but if that is the case, then the related permissions for purchase orders for those stores on the primary will need to be disabled manually in order to prevent purchase orders for those stores being editable on both sites.
By default, prescriptions and any other operations in dispensary mode which affect stock levels are not synced to the sync server, unless the Include transactions in sync option is enabled in the store sync preferences, as these can potentially generate a lot of sync traffic and there is usually no need for the central users to have this level of detail - the same site will usually have another store which supplies the dispensary and its transactions will be synced, and that's usually enough to infer usage for the dispensary store.
If this preference is switched off in a dispensary store on a remote site, the following data will not be synced back to the central sync server:
If the preference is switched on, all of the store's transaction & stock data will be synced to the sync server.
Patients in mSupply are a special kind of customer, but for the purposes of synchronisation, we need to treat them differently - more like store-specific data rather than system data. This is because patient data is often locally controlled rather than centrally.
Since mSupply v4.09, patients have a home store, initialised either according to the store they were created in, or according to their most recent prescription. Patients and their related data (patient medication records, repeats, insurance policies) can only be edited in an active dispensary store on the same home site where their home store is active.
Patients and their related data records will be synced to the primary server, and forwarded on to any other site which has an active/collector store in which the patient is visible. Prescriptions will be allowed in dispensary stores on any of those sites, except for repeats which can only be processed in dispensary stores on the patient's home site.
Newly created patients will also be made visible in any other dispensary stores on the home site, depending on the store's visibility preferences. Subsequently, patient visibility is controlled from the primary server in the same way as for other name (customer & supplier) records.
Abbreviations, item directions, insurance providers and patient event types are treated as a special kind of system-specific data i.e. they are editable on the primary, but only synced to sites having at least one active dispensary store.
Prescribers are also treated as a special kind of store-specific data, like patients i.e. they are editable in any active dispensary store on their home site, synced back to the primary server, and shared with dispensary stores on other sites where they've previously prescribed.
Watch this space…
Transfers occur when there are two stores involved in a transaction, and includes stock transfers, requisitions (from a mobile store) and internal requisitions (from another desktop store). In a syncing system, very often these two stores are not active on the same site, so there has to be extra processing to ensure that both halves of the transaction are synced to both the initiating store/site and the responding store/site.
Both stores need to exist on both sites, and usually the initiating store is a transfer store on the responding site, and vice-versa. As of mSupply v3.83, unless both stores are active on the same site (in which case, everything can be done locally), the bulk of the processing is done on the central sync server when it detects the initiating half of a transfer transaction. In simple terms, the logic is something like this:
The Sync server module is the component that controls all the logic of the sync system described in this chapter. This module is priced separately - refer Pricing
Any communication through the web to an mSupply central server requires the Web Server Module. This module is priced separately - refer Pricing
Each sync site requires an internet connection. This doesn't have to be on all the time for each satellite server, but at least an hour or so per day or per week, depending on the transaction volume, how often primary server data needs to be updated, and the speed and latency of the internet.
Obviously, the internet needs to be on at the central server at the same time as any other sync site that it will communicate with. For this reason, the central server needs to have high availability, and so in most cases, will be cloud hosted.
Note: the synchronisation system can be disabled completely or paused in the preferences (see the 16.01. General preferences page for details).
If you click the “2 circular arrows” icon at the bottom it will initiate an immediate synchronisation and update the statistics on the number of records remaining as sync progresses.
If there are queued sync records, there will be a message at the bottom left of the navigator which shows the number of sync records in the queue. If this is not going down, there may be an entry in the log.
Extending an mSupply deployment from a single computer to a synchronised system is something that should not be attempted without consulting with experienced experts at Sustainable Solutions! However, there is a lot of preparation ground work that can be done beforehand:
Misconfiguring of store or site settings can corrupt data across the synchronisation system. This should only be done by someone trained to do so and with guidance from the mSupply team
How mSupply handles sync sites was 'refactored' and released in mSupply v5.07 (2022-03-22). This refactoring was significant and has resulted in a simpler and more strictly controlled way of managing sync sites. Rather than use the methods documented in this section, it is highly recommended to use the new tool as documented in Synchronisation Sites.
If you are using mSupply v5.07 (2022-03-22) or later, it is highly recommended to use the new tool as documented in Synchronisation Sites, but if you insist on going 'old school' you can use the site wizard.
To move a store from one site to another means to make it not Active on the 'From' site, and Active on the 'To' site. By default, mSupply will leave the store configured to maintain a full Collector copy on the 'From' site with all the associated sync traffic. This is not normally desired. Except for this process of determining which site a store is Active on, all sync settings are governed by store visibility settings.
If you are using mSupply v5.07 (2022-03-22) or later, the methods described here will not work. You will have to use the new tool as documented in Synchronisation Sites.
This process involves editing store sync settings which is dangerous. Editing store sync settings must happen on the central server and is restricted (by password) to Sussol technicians. Please consult with us to coordinate this. The full process is documented here for your information.
If the 'To' store is the central server, then this same procedure applies
If you are moving the store from Mobile to Desktop of vice versa, this process will not change the site type. As of 2020-10-02 this must be done by Sussol technicians only by use of the record browser.
Previous: 28. Frequently Asked Questions | | Next: 29.02. Synchronisation Sites |