Releases

2022-10-20

Release 11
Deployment started 19 October 2022 at 23.00 and was completed 20 October 2022 at 01.15.

The main changes in release 11 are as follows:

• SMVS API 2.1 will be removed as we informed about in early 2022 as well as during the information meeting held by Solidsoft Reply.
• New version of SMVS API 2.4. The changes that mainly affect the API are:
  • The response includes the EMVS alert code (e.g. A2 or A3) in the response from the API when an alert has been created. More information about these EMVS alert codes can be found here: https://developer-ite.nmvo.eu/apis/emvs-alert-codes
  • “isIntermarket” has been added to the API response indicating whether the transaction was completed in the Swedish system or required an intermarket transaction, i.e. a call to another national system. The flag is added to the response only when the value is “true”, if the flag is missing it implicitly indicates that the transaction has been carried out locally in the Swedish system SMVS.
  • A number of new operation codes are added to the responses to the new API version to support upcoming new functionality. However, the underlying functionality will only be implemented in Release 12, which means that these new response codes will not be able to be given in Release 11, but are included so that a new version of the SMVS API is not needed in Release 12.
  • For information, there is a new field in the response to an alert where e-VIS has the option to add a link to the national alert management system. As this is not used by end users in Sweden yet, the field is empty.
    
• New version of SMVS Reporting API 2.4:
  • Improved information in responses about which report formats are ready and can be downloaded, and changed so that “failed” is only displayed if all report formats failed to be generated.
  • Improved error handling when using incorrect report format.

2022-04-13

Release 10
Deployment started 12 April 2022 at 23.00 and was completed 13 April 2022 at 01.15

• The main changes are:
  • Removal of API version 2.0
  • Deprecation of API version 2.2
  • Introduction of API version 2.3:
    • Add information to verification responses to help client systems determine if the user has the option to reactivate a deactivated pack
    • Add the name of the product to the API response so that the end user can check the product they have in hand is the same as that which was verified
    • Note: If your end-user system does not specify which API version is used when making requests to SMVS, the requests will be made to the new API 2.3 after the release and then need to be able to handle the above-mentioned information in the responses.
  • Possibility for end users to update the name of Prime contact in the SMVS portal without having to update the e-mail address (e.g., when the organization use shared mailbox).

Test environments

• ITE: SMVS Release 10 has been available on ITE since February 2, 2022.
• IQE: SMVS Release 10 will be available to test on the IQE environment after February 24, 2022.

2021-10-27

Release 9 of SMVS was launched on October 27, 2021 at 23.00 CEST

• Main changes
  • Removal of weak underlying security protocols (Cipher Suites) to ensure and maintain a secure system and minimize the risk of information security incidents occurring. Release Notes for release 9 provide a complete list of which Cipher Suites that are still supported after release.
    Note: To continue to have a working integration with SMVS, your system must support at least one of the Cipher Suites that are supported in SMVS after Release 9. Action must therefore be taken before Release 9. If you are unsure about this, we ask you to contact your IT supplier.
  • SMVS API version 1.5 is removed and request using API version 1.5 will no longer respond.
    Action must therefore be taken before Release 9. If you are unsure about this, we ask you to contact your IT supplier.
  • After Release 9, requests to SMVS without specifying the API version will be automatically redirected to the latest API version (API 2.2). The recommendation is therefore to always specify which API version to be used in the requests.
  • API version 2.1 is deprecated but can still be used. It will be removed in Release 11, which is scheduled to take place in the autumn of 2022.
    Note: SMVS API 2.0 will be removed in Release 10 in the spring of 2022.
  • More detailed information about the release can be found in Release Notes which are available on request by emailing info@e-vis.se.
• IQE environment
  SMVS Release 9 has been available for testing on the IQE environment since 27 August. This means that you can now test and verify that the above changes do not have a negative impact on your system.

2021-04-29

Release 8.0 of SMVS was launched at 01.30 (CET) on 29 April 2021.

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. 
The following changes included in the release may affect end users – pharmacies, distributors, wholesalers, and hospitals:

• 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.

2020-11-12

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
• Infrastructure
  • 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 40.127.236.158 from now on.

2020-05-06

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:
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • Other supported protocols that are currently secure but have identified vulnerabilities that can be exploited in the future:
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA256
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_128_CBC_SHA

2020-01-16

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.

2019-10-31

Release 6

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.

Open API:

• 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:

1. 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.
2. 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.