Release 8.0 of SMVS is scheduled to be put into production by the end of April 2021 and will be available on the IQE environment in mid-March. The release does not contain any major functional changes, but is about giving end users, e-VIS and the Swedish Medical Product Agency better possibilities and facilitating investigations of alerts.
Note that there may be some minor adjustment of the scope depending on if something is found in the final tests that are currently underway. If this happens, the information will be updated.
The following changes included in the release may affect end users – pharmacies, distributors, wholesalers, and hospitals:
- To further improve security, some of the underlying security protocols (Cipher Suites) with identified vulnerabilities are removed.
Note: this means that if your system uses any of the Cipher Suites that are removed, you must make sure to start using those that are supported before Release 8 goes live.
For furhter information on which Cipher Suites are removed please contact e-VIS.
- API version 2.0 will be unsupported but can still be used. It will be removed in Release 10, which is now scheduled for spring 2022.
- When new Locations are added or old ones are updated, postcode now become a mandatory field. This is because some of the authorities’ reports depend on postcodes being included in locations.
- New version API 2.2 with the following improvements:
- Review of Swedish translations of responses from API where there have previously been some inconsistent answers. Some new translations have also been added as a direct result of the improvements listed below.
- When verifying a package that has previously been decommissioned, the response shows whether the package has previously been decommissioned in the same place or in another place.
This change is a request from the Swedish end users that has now been realized. The need has arisen based on requirements from the Medical Products Agency.
- To facilitate the investigation of alerts, the error response “Serial number not found” and “Batch not found” are differentiated.
▪ An error response that indicates that a batch not found indicates that the batch is not uploaded in the system at all, which could be done by the MAH/OBP.
▪ If an error response is given that the serial number not found, it indicates that a single serial number is missing even though the batch is charged which should trigger a more thorough investigation.
o If a Bulk API request contains several packs with errors that generate alerts, an alert ID will be created for each alert. Previously, only one alert ID was created per bulk call, even though there were more than one incorrect pack in the request.
o If end-user systems send incorrect data, e.g. due to poorly implemented system, a new error code and response is introduced (C0020003: “The product code or batch is unknown locally. Bad Data Sent to Hub. Do not retry.”) to reduce the risk of the end user system sending the incorrect request again. Previously, the response was given B1020000: “The product code or batch is unknown locally. Inter-market communication error. You may retry later.” which indicated that the call would be resent but when the data was incorrect would give the same answer and risk the end user system may get in a loop continually resubmitting the same request.
In addition, a number of changes are included that contribute to better usability, increased security and system stability. The most important of these are:
- Support for the TLS 1.3 security protocol has been added. The system will continue to support TLS 1.2.
- To reduce the email backlogs and delays the system will use a different email provider.
There is also a change #52051: “Repeated Decommission Warning for local transactions” where, in the same way as for supply, it will be possible to set a threshold before creating alerts. If an actor attempts to decommission a pack and the request is from the same location and to the same state as the previous decommission operation then a warning will be returned, rather than an error, and no alert will be raised. However, if an actor tries more than the configured threshold an error will be returned, and an alert will be raised. Initially, this function will NOT be activated as some work is done on EU-level to reach an appropriate and common threshold so as not to increase the risk of potential counterfeits entering the market.
Release 7.1 of SMVS was launched at 00:40 (CET) on 12 November, 2020.
As previously communicated, the following changes will be made that may affect end users – pharmacies, distributors, wholesalers and hospitals:
- Change in check of expiration date against scanned 2D code
The day of the expiration date is not verified and thus does NOT cause an alarm if the day contained in the 2D code does not match the day of the expiration date that is uploaded. In practice, this means that only the year and month are checked during verification against SMVS – i.e. the information that is human readable on the pack.
Note that this change applies regardless of the version of the API used by the end user systems.
- When a request to another national system (IMT) is made and generate alerts, alerts are from now on created both in the national system that initiated the request (where the physical pack is located) and in the fulfilling national system. The change make investigation of alerts raised via IMTs easier.
- Version 1.5 of the API is set to deprecated and unsupported. Version 1.5 will be available to use for an additional 12 months, i.e. until October / November 2021 to ensure that end users have plenty of time to adapt their systems.
- Default version of API used in request, if no API-version is specified in the request, is still version 1.5.
- Updates in new API version 2.1
- Distinguish Location in Operation Codes: Possibility to distinguish if a previous decommissioning has taken place in the same or another location.
- Results Returned on Successful Reactivation: When a reactivation takes place on pack where the batch or product is not active (expired, revoked or withdrawn), the system respond with http status 200 OK. The response means that the reactivation went well and respond that the packaging is expired, revoked or withdrawn. One deleted and six new Operation codes, see https://developer-ite.nmvo.eu/operation-codes for more information.
- Standardized the Json format for end user reports: New JSON format for reports via the Reporting API
- Old URLs (which contain port numbers, for example 8978) are deactivated and will stop working. See which URLs apply here: https://developer-ite.nmvo.eu/endpoints.
- Static IP address is introduced for SMVS and the current IP address is updated. The static IP address in production will be 18.104.22.168 from now on.
Release 6.2 of SMVS was launched on May 6, 2020, at midnight
The content of the release includes the last trench of NCA reports, several bug fixes and as earlier communicated (may impact the end users -pharmacies, distributors, wholesalers and hospitals):
- Removal of support for TLS 1.0 and TLS 1.1, both of which are old security protocols with a number of security flaws. Remaining is only the support for TLS 1.2.
- The following underlying security protocols (Cipher Suites) will be supported:
- Recommended and strongest protocols:
- Other supported protocols that are currently secure but have identified vulnerabilities that can be exploited in the future:
- Recommended and strongest protocols:
The Release 6.1.2 of SMVS was launched on January 15, 2020 at 22.00.
The content of the release are in addition to bug fixes:
- The second group (of three) of NCA reports, for Medical Products Agencies to practise their supervision.
- Alert id: Modification to Alert id Format to reduce the probability of duplicate alerts ids. The format is extended by a 4 characters to give a format as XX-XXX-XXX-XXX-XXX-XXX (A hyphen and alphanumeric characters).
- API error message: Rate limiting (i.e. throttling) error message is now presented in local language.
- SMVS Portal: Users are now able to add permissions to a role with a default role name used by another organisation type.
- Reports: If rendering of a report in PDF, XML or JSON format failed, it was previously not possible to download the report in any format even if that format was successfully rendered.
- Reports: A report is now generated even if a double quote is present in the parameters of the string sent in the Reporting API.
This release, which is scheduled to be deployed in production 2019-10-31, will include both functionality for release 5 and 6 due to the planned release 5 being postponed (see previous status 2019-08-05).
Previously, there was a change regarding deprecated support for TLS 1.0, but it has caused problems for end-user systems in Sweden and other countries. It has therefore been decided to retain support for TLS 1.0 at least until the next scheduled release in December 2019.
In addition to several bug fixes, the following changes are included:
- The authentication token obtained from the Authentication API is valid for 30 minutes instead of 9 hours.
- Introducing Azure Application Gateway and Azure API Management which provides a flexible solution for load balancing, advanced traffic routing and an infrastructure for publishing, securing and managing APIs.
- Via API Management, a rate limit is set for the maximum number of requests that can be made from a terminal (location / equipment) within a specific period of time. This change will minimize the risk abusive use of the API and of Denial of Service (DOS) attacks. If the call limit is reached, subsequent calls will be denied and an error code (70020000) with an error message will be given in response. No new error code is created for this, so no customization in the end-user system needs to be made. The rate limits will initially be:
- 1500 calls/5 min/IP address for the Authentication API
- 800 calls/5 min/location (equipment) for Pack API
- 200 calls/5 min/location (equipment) for Reporting API
- Via Azure Application Gateway, version management of the SMVS API is introduced. This means that parallel versions of the SMVS API can exist and the requesting system determines which version to request. The current version of the API will be requested by default if no version is specified. Therefore, no change needs to be made to adapt the SMVS API directly in connection with the update.
- Read more about how versioning works here: https://confluence.solidsoft.com/display/EU/Versioning
- Versions available in SMVS API are 1.5 and 2.0. Read more about the new 2.0 here: https://confluence.solidsoft.com/display/EU/2.0%3A+Changes
- In the current version of SMVS there is a configurable limit that indicates how many times a day a pharmacy / wholesaler for a location (location) may make an incorrect manual entry before an alert is generated. This limit for incorrect manual verification / deactivation per location is removed and an alert will be generated in the same way whether it is a call based on manual or scanned input.
- NCA Reports
- Reports intended for the Swedish Medicines Agency for their supervision and transparency of the system
- Open API
- The end users and IT vendors can use Open API to get a description of what services the SMVS API provides and how they are requested.
5 August 2019
Release 5 of SMVS postponed until later this fall
In addition to the national e-verification systems, the European e-verification system (EMVS) also consists of the EU hub. The EU hub is the central system of EMVS where product and packaging information is uploaded. The EU hub also manages communications between all national systems in all countries. This summer, a new release of the EU hub (version 1.5) was planned. During the final tests, a critical error was detected that could not be corrected before the planned release date. The EU hub version 1.5 has therefore been postponed to the future later this autumn at the same time as the next release 1.6 in November (see EMVO_LoA_0083_EU Hub Release 1.5_announcement.pdf).
Release 5 for SMVS is fully developed and was ready to be deployed but when the EU hub version 1.5 is now stopped the knock-on effect is unfortunately that also Release 5 of SMVS is affected and postponed until later this fall. Release 5 must be tested against the correct version of the EU hub, which is not possible at this time. Right now, planning at European level is underway to plan and sync national system releases with EU hub releases.
Discussions are now underway with involved parties and the plan is right now that releases 5 and 6 will be merged and will take place at the end of October.
1 July 2019
Upcoming release of Swedish Medicines Verification System
In a future release of the Swedish Medicines Verification System (SMVS), the system will be updated to version 5.0. The purpose of the release is primarily to improve the system in terms of reliability, usability and manageability and not to deliver new functionality.
Date of release 5.0 not yet determined
During the spring, several minor urgent updates have been made to address some instability in the system. Due to these more unplanned updates, there is currently no exact date for when release of version 5.0 will take place. At present, the planning from the supplier of the system is that the update is scheduled to take place in the middle / end of August 2019. e-VIS is able to adapt when the update is to take place after it has been tested and approved and the date of the update will be adapted based on the conditions that is available in Sweden with holiday season and code stops during the summer months.
As soon as a date is set by the supplier, e-VIS will announce when the update will take place in Sweden.
Content in Release 5.0
Important to know that this delivery does not break the backward compatibility of the API against the SMVS but that this update introduces a version management of the API (please see below). The version management does not require any action from end-users on this update but enables changes to the API to be handled in a smooth way in the future.
Overall changes in version 5.0
Performance and Data Management Improvements:
- Introducing Azure Application Gateway and Azure API Management providing a flexible solution for load balancing, advanced traffic routing, and an infrastructure for publishing, securing and managing APIs.
- Via API Management, a limit is set for the maximum number of calls that can be made from a terminal (location / equipment) within a time period to minimize the risk of Denial of Service (DOS) attacks. The limit will initially be set to 800 calls / 5 min. If the call limit is reached, subsequent calls will be denied and an error code (70020000) and an error message will be given in response. No new error code is created for this, so no adaptation in the end users’ systems needs to be done. With the introduction of this limit, e-VIS has contacted the end users of the system to find an appropriate limit for the calls in order to minimize problems in the introduction of the maximum number of calls.
A future consequence of this limitation of calls per unit of time is that it will be advantageous to adapt its set up against SMVS with more so-called equipment’s per location. If you make frequent calls to SMVS (even if they only occur during certain periods of time), a distribution of the calls through several equipment’s will distribute the load and ensure that the calls can be made without interruption.
- The Azure Application Gateway introduces version management of the end user API (pharmacy and wholesaler). This means that several parallel versions of the SMVS API can be used and the calling system determines which version to call. The current version of the API will be called by default (default) if nothing is specified. No change therefore needs to be made to adapt to the API in direct connection with the update.
- This means that end users and IT providers can call the Open API that responds with a description of what services the SMVS API provides and how to use them.
Alarm limit for manual input:
- In the current version of SMVS there is a configurable limit that indicates how many times a day a pharmacy / wholesaler for a location may make an incorrect manual entry before an alarm is created. This limit for incorrect manual verification / deactivation per site is removed and an alarm will be created in the same way regardless of whether it is a call made from manual or scanned input.
General Portal Improvements:
- The Batch expiry date field in EVA (Emergency Verification Application) changes to a free text field to allow entry of expiration dates ending with “00”.
- Mandatory fields are now clearly displayed to users.
- Layout in the portal changes to be adapted to different screen sizes.
Portal improvement for e-VIS:
- e-VIS has better opportunities to see which locations and equipment’s an end user sets up for their organization. This primarily facilitates investigations of potential counterfeits.
13 June 2019
SMVS has been updated to address two issues:
- Reduce the risk that performance problems that have been discovered in another national system also arise in the Swedish system. The action means that a configuration file is stored (cached) for a long time so that the system does not need to reload it unnecessarily.
- Get a uniformity throughout the EMVS in terms of timing and comparisons of time stamps. The problem has caused that status changes on packaging between different national systems have not always reported correct status back. All different systems in EMVS (the national systems from Solidsoft and Arvato as well as the EU Hub) need to be updated, that is, with this fix the whole problem is not gone but this is expected to be completely rectified after a release of the EU hub later in summer.
The update does not involve any changes in the API that end users (pharmacies / wholesalers / distributors / etc) use, which means that no action needs to be taken for the end users after the update.
11 May 2019
On Saturday May 11th at 22:00-22:30, two changes are made in the Swedish e-verification system:
- Performance improvement for SMVS to reduce the risk of long response times.
- Extension of the information for the alarms that occur to simplify the handling and investigation of potential counterfeits.
31 March 2019
The Swedish e-verification system (SMVS) will be updated on Sunday March 31 th at 22:00-22:30 with a critical fix. This means a downtime on SMVS in about 30 minutes. The reason for the update is a problem that has been discovered in another national system within EMVS that needs to be addressed as soon as possible in order to minimize the risk that the problem also arises in the Swedish system. If it is not addressed, there is a risk of a large number of faulty alarms for NMVO, EMVO and OBP that occur in times of high load. This can in turn cause an overload in the network and have an impact on the entire EMVS.
7 February 2019
Release (4.1) is implemented to correct known, documented deviations and requested minor changes/additions and contains:
- 14 corrections, ie. reports which are not correct, messages with inaccurate translation, inaccurate handling of codes in IMT (Imtermarket Transactions, adjustments after security audit
- Some changes, of which 4 are connected to safety and performance improvements and 2 to reports, ie. access to ”Contracted WS stakeholder report” for clients in National systems system
12 December 2018
SMVS has been updated to version 4.0. SMVS now fully supports the verification and decommissioning of multi market packs by ensuring proper status throughout the European system. MAH can now also recall batches in the national markets. A web interface is available for pharmacies and distributors to enable and disable packaging by manual entry in case of emergency, if your own system for some reason does not work. A number of new reports are now also available to different users of the system. Additionally, user notifier functionality has been developed to enable e-VIS to notify portal users directly through the portal.
30 September 2018
Version 3.0 of SMVS is now available with enhanced functionality. Pharmacies and Wholesalers now have possibility to create reports via a new API. The portal used by pharmacies and wholesalers have new functionality for handling of roles and responsibilities, together with handling of clent ID and password for the technical connection to SMVS. The interface for manufacturers via the Hub has been updated so that they can verify the status of the packages in SMVS, recall batch and programmatically call SMVS via an API to get reports about their packages that are in the SMVS. A number of new reports are available for the different stakeholders.
6 July 2018
SMVS is now updated to Release 2.0 with enhanced functionality. Pharmacies and Wholesalers can download Product Master Data for products available in SMVS. MAH can update the status on earlier uploaded packages. If products are to be sold on more than one market the status changes will be synchronised to make the information up-to-date. See below a table presenting the new functions.
25 May 2018
Release 1.1.2 fixes two problems concerning the upload of packages into SMVS from EU-Hub. Firstly a problem with an alert (duplicate pack alerts) sometimes was created during uploading of packages despite no such error occurred and secondly problems that only parts of the packages intended were uploaded.
18 May 2018
Release 1.1.1 fixes a problem concerning certain special characters (specified in GS1 Character Set 82) in batch id were not uploaded correctly into from EU-Hub.
10 April 2018
e-VIS is approved by the European organisation, EMVO, and can be connected to the production environment of EMVS. It is now possible to upload data to the EU-Hub for products intended for the Swedish market.
3 February 2021