Releases

2026-05-20

Deployment of release 18
The deployment of release 18 started on May 19, 2026 at 23:00 (CET) and was completed on May 20, 2026 at 01.00 (CET).

IMPORTANT UPDATES!

Updated Certificate Authority (CA)
With the deployment of SMVS Release 18, a new Certificate Authority (CA) from the SSL provider will be put into operation. The updated Root CA certificate are required for systems communicating with SMVS to trust the public certificate that SMVS will use following the R18 release. If the certificate is not installed, it will NOT be possible to connect to SMVS. This change should not cause problems if the servers/terminals that communicate with SMVS are up to date.
To guarantee functionality after deployment, please ensure the below certificate (or any cross-signed Root CAs) are in place on the machines, servers and terminals, where the software connecting to the SMVS running (i.e. directly establish SSL/TLS connection with SMVS): Sectigo Public Server Authentication Root R46

The change is already in place in SMVS’s ITE test environment, which means that you can test your connection already now for those servers and terminals that communicate directly with SMVS. Navigate from your servers/terminals to https://developer-ite.nmvo.eu/ in a web browser. If you access the login page, you’ll be ready for the deployment of Release 18 and can rest assured that everything is working as it should.

Referrer-Policy header in responses from SMVS APIs
In the previous release, a change was introduced in the SMVS portal around the Referrer-Policy header that controls how much information is included in requests made to a website or an API and this change is now made on the SMVS API. The policy specifies whether the information includes origin, path, and query string components. Information improves security and privacy by limiting the amount of information shared and reducing the risk of accidental leakage of sensitive information. The responses from all versions of all APIs (Authentication, Verification and Reporting) will contain the Referrer-Policy header and must be able to be received and managed by the end-user systems. For more information, visit the ITE Developer Portal: https://developer-ite.nmvo.eu/apis/referrer-policy

This should not cause any problems, but we still recommend that it be checked when release 18 is available on our test environment IQE (from March 19)

OTHER UPDATES

Improved view of locations in the SMVS portal
The ‘Locations’ tab in the SMVS Portal has been improved for end users with the ability to perform the following actions:

• View and export activity data for the location and its clients
• Searching for location and equipment via Client ID
• Expand the list of locations to view the equipment at each location
• Export the list of locations in CSV and Excel formats

Secondary contact person for organisations in the SMVS portal
At present, it is only possible to have a contact person (prime contact) set up in SMVS. The contact person currently receives e.g. messages from the system if e-VIS has proposed a change in information about the organisation and locations (locations). Adding an additional contact person reduces the risk of dependency and missing information. More information on how to use this feature can be found in the user guide that will be uploaded to e-VIS web https://e-vis.se/en/pharmacieswholesalers/ in connection with release 18 being made available on the IQE test environment.

Test environments for release 18
ITE: SMVS Release 18 available on ITE since February 5, 2026
IQE: New releases available on the IQE test environment from March 19, 2026

2025-11-05

Release 17

The deployment of release 17 started on November 4, 2025 at 23.00 (CET) and was completed on November 5, 2025 at 01.00 (CET).

Important changes in Release 17

New fields for contact information for a location in the SMVS portal
With release 17, the SMVS portal is enhanced to allow contact information to be added when creating or editing a specific Location. The new fields are email address, phone number and a field for approving that the contact information may be used in the Alert portal (NMVS Alerts) which is used for handling alerts. e-VIS needs contact information for the individual pharmacies and wholesalers in order to be able to investigate exceptions and alerts from the e-verification database. If the user approves that the contact information may be used, e-VIS will be able to enter the information into the Alert portal to have correct and updated contact information.

Referrer-Policy header in responses from the SMVS portal and SMVS API
The change has no impact on the use and integration with SMVS but makes the use more secure.The SMVS Portal will return the Referrer-Policy header to browsers, requesting that they do not include any referrer information. This information improves security and integrity by limiting the amount of information shared with third-party websites or APIs and reducing the risk of accidental leakage of sensitive information. In release 17, this is introduced on the SMVS portal. From Release 18 (subject to confirmation), the SMVS shall implement the Referrer-Policy header in all API versions and responses, This means that the responses from all versions of all  SMVS APIs will contain the new header and end-user systems need to be able to receive and handle the header. Please refer to the ITE Developer Portal for more information. The ITE API documentation and sandbox have been updated to enable IT Suppliers to prepare for this change.

Exclude NMVS portals from search engine indexing and make e-VIS visible on the SMVS login page
End users sometimes search for the SMVS portal login page using a search engine (e.g. Google) and may find a link that may belong to another country’s NMVS portal. Failed login attempts lead to security incidents in the “foreign” NMVS, while e-VIS cannot provide the end user with proper support because the root cause cannot be easily identified unless it is realized that the wrong NMVS portal has been used. Therefore, all NMVS Portal pages across all environments (Production, ITE, and IQE) are excluded from search engine indexing to enhance security and prevent public discovery via search engines. If you are unsure of which URLs applies, please contact e-VIS at info@e-vis.se.
To clarify that the correct login page is being used, from release 17 the login page will state e-VIS Medicines Verification System instead of the general National Medicines Verification System that it says today. The page footer displays the environment, build number, and release – and remains visible during Portal navigation.

API versions

• SMVS Reporting API versions 2.5 and 3.0 will stop working when release 17 is deployed in production and users using Reporting API versions 2.5 or 3.0 must immediately switch to a later API version.
• SMVS Reporting API versions 3.1 and 3.2 are set to deprecated status and are planned to be removed in approximately 1 year, i.e. during Q4 2026.
• Note: The removal of the SMVS Reporting API versions does not affect the ability to verify and change the status of packages.

Table of Reporting API versions and how they will be handled in the next planned releases:

Information on functionality and current API versions, see Solidsoft ITE Developer Portal (https://developer-ite.nmvo.eu/).

2025-05-21

Release 16

The deployment of release 16 started on May 20, 2025 at 23.00 (CET) and was completed on May 21, 2025 at 01.00 (CET).

SMVS API version 2.4 will stop working with the release. This means that:

• End users using API 2.4 will not be able to connect to the Swedish e-verification database after the release in May. The end users who currently use API 2.4 must immediately update their systems so that the latest API is used.
• The pharmacies that have connection to IQE API 2.4 in their test environments will no longer have access to the IQE environment for testing as of March 3, 2025.

Test environments for Release

• ITE: SMVS Release 16 is available on ITE since February 26, 2025.
• IQE: SMVS Release 16 is available to test on the IQE environment since March 3, 2025.

Overall changes in Release 16
API versions

• NOTE! SMVS API version 2.4 (both Verification and Report API) will stop working when R16 is deployed in production and the end users who are on API 2.4 must immediately switch to a later API. The users who are still using API version 2.4 will be contacted separately.
• Verification and Report API version 3.0 are set as deprecated and are planned to be removed in about 1 year, i.e. during Q2 2026.

Table of SMVS API versions and how they will be handled in the upcoming planned releases.

Information on functionality and current API versions, see Solidsoft ITE Developer Portal

Upgrade a normal user in SMVS to Super-User
When an organisation in SMVS only has one user who is a so-called super-user with the highest permissions and that person leaves, the organisation often wants to ensure that another existing user takes over the role of super-user. With a change in R16, e-VIS can now upgrade a normal user in SMVS to super-user in these cases when the organisation cannot fix it themselves.

Others

New countries connected to EMVS

• Greece has connected its e-verification system to EMVS on February 6, 2025. This means that Greek medical packs can have a 2D code and batches intended for Greece will be uploaded to EMVS. There will be a transition period with different answers for Greek packages if they are verified by pharmacies and wholesalers in Sweden depending on whether they are fully/partially/not uploaded.
• Italy will start tests for connection in 2025. Italian packs will be similar to e.g. Portuguese packaging contains a benefit number in the 2D code. This benefit number is identified in the 2D code through AI 716 and this element should therefore be overlooked when Italian packs is handled and scanned in Sweden.

Access to reports
Since Release 15, end-users have access to reports in SMVS portal to be able to check how a packs / specific combination of product code and serial number has been handled within the organisation. This can, for example, be valuable for checking when a specific package has previously been deactivated and if the package has previously been deactivated by a pharmacy within the same pharmacy chain.

End-user forum 11 April 2025
On April 11, 2025, e-VIS will organise an end-user forum where a presentation of how the reports can be used will be presented. A Teams invitation has been sent.

2024-11-06

Release 15

The deployment of release 15 started November 5, 2024 at 23.00 (CET). and was completed at November 6, 2024 at 02.00 (CET).
SMVS API version 2.3 will stop working with the release.

Overall changes in Release 15

API versions

• NOTE! SMVS API version 2.3 (both verification and report API) will stop working when R15 is deployed in production, and we recommend that those end users who are on API 2.3 must immediately switch to a later API. The users still using API version 2.3 have been contacted separately.
• Report API version 2.5 is set as deprecated

Reports in SMVS

New reports

Four new reports becomes available to end users (pharmacies and wholesalers) in the SMVS Portal and via API to ensure that end users can investigate warnings and alerts more efficiently without having to generate multiple reports, or multiple instances of the same report. e-VIS also hopes that the new reports mean that end users will more easily be able to investigate the history of an individual package themselves.

• End-user Pack Disclosure Report: this report details each transaction associated with an Alert ID performed by the requesting end user. To investigate alerts internally, especially when the status of the pack does not match what is expected.
• End-user Pack Audit Trail Report: same type of report as above. However, this report details each transaction associated with a unique pack (product code and serial number) performed by the requesting end user. To investigate alerts internally, especially when the status of the package does not match what is expected.
• End-user Batch Disclosure Report: this report details each transaction performed related to a specific product code and batch ID combination, performed by the requesting local organisation. It can be filtered to provide only transactions from a certain location within the organisation.
• Organisation Administration Activity Report: New report designed for local organisations to be able to see all changes that have taken place for the organisation in the locations in SMVS. The report is generated based on a time period and lists all changes that occurred during the time period.

Improved report

• Transaction Log Client Report: provides list of all transactions initiated at a location within an organisation. However, the current report has limitations in its representation of transaction details, so the report is being enhanced to include more detailed and specific information.

Extended information for a location

When location is created or when details are changed for a location, legitimacy information can be added. This can be a national authorisation number for a pharmacy or wholesaler according to the requirements found in Article 37 b of the Delegated Regulation.

Extended notifications to end users for NMVO updates

In case of various updates to the end users’ information in the SMVS portal, e.g. suspension, reactivation or removal of information for an organisation, by NMVO, the organisation will be notified by e-mail. By default, the primary contact receives the notification, but with Release 15, NMVO can choose to also notify one or more other recipients.

Automatic suspension of inactive users

New functionality to automatically suspend inactive users in the system.
NOTE! This functionality is NOT enabled in the Swedish system, but we will evaluate and see if and when we enable it.

Improvements in test book on IQE

• New test cases to test, among other things, inverted 2D code (white dots on a black background) and packs belonging to the NIXIT batch
• Files of the file types .log and .txt can now be uploaded. File types supported now are: .jpg, .pdf, .docx, .png, .csv, .xlsx, .log, .txt.
• Issue fixed so that the files that are uploaded can have the file extensions in both lowercase and uppercase letters. Previously, only lowercase file extensions were allowed, e.g. .pdf and not .PDF.

Others

Information on functionality and current API versions, see Solidsoft ITE Developer Portal (https://developer-ite.nmvo.eu/).

NIXIT and the disconnection of the Northern Ireland system

Northern Ireland will leave EU on 1 January 2025 and then the e-verification system in Northern Ireland will be disconnected. This means that after 1 January 2025, a pack belonging to a batch that was previously only uploaded in Northern Ireland (so-called Single market pack) will give the end user a response that verification or deactivation of the pack is not possible (response code B1020001).

The response was proactively introduced in Release 14 in all API versions. The answer will be relevant after 1 January 2025 and will be generated in cases where the batch indicates that the pack were previously only uploaded in the UKNI system.

2024-05-15

Release 14

The deployment of Release 14 started May 14, 2024 at 23.00 (CET) and was completed at May 15, 2024 at 05.00 (CET).
The release should have no impact on current connectivity to SMVS.

However, a new SMVS API version 3.1 is included, and e-VIS recommends all end users to start using it as soon as possible. As standard, SMVS has 2 releases per year, one in April/May and another in October/November. The plan is that if a new API version is required for a release, it will from now on be made available in the release that takes place in April/May.

NOTE: API version 2.3 will stop working in October/November 2024 and we recommend that end users who are on API 2.3 immediately switch to a later API version.

Changes that impact all version of the SMVS API

• New operation code to prepare for removal of the Northern Ireland national system (also known as NIXIT) on 1^st of January 2025.
  B1020001: ” Produktkoden eller batchen är okänd i det nationella systemet. Databasen som batchen är uppladdad i är permanent bortkopplad från systemet. Förpackningar av batchen kan inte avaktiveras. Verifering eller avaktivering av förpackningen är inte möjlig. “.
  Note: The operation code is included in this release but will not be relevant until after 1^st of January 2025 and will then only affect batches that were only uploaded to the Northern Ireland national system.
• New operation code to be able to handle batches that are exempted from the regulation regarding security details. Each exception will need to be approved by the Swedish Medical Products Agency and the exception will be approved for a specific product at batch level.
  41020006: “Batchen är undantagen från kraven i FMD.”
  Note: This functionality is added in release 14 but its use will be evaluated in 2024.

All available API versions will thus be able to respond with the above operation codes.

New SMVS API version 3.1 is introduced
SMVS API 3.1 brings, among other things, the following changes that may impact the end-user system’s connection to SMVS for those who intend to start using API version 3.1.

• New fields in the response indicating if the batch has been recalled or if the product has been withdrawn. In cases where a pack is supplied or decommissioned for another reason (e.g. locked or destroyed), today the user does not receive information about whether the batch has been recalled or the product withdrawn but is only informed that the pack has been decommissioned. To address this, two new fields in the responses will be sent to enable the end user to be informed of this, “batchState” and “productState“.
• New operation codes when the format or length of the batch id does not match:
  41020007, 41020008 and 41020009: ” Batchens identifierare matchar inte den identifierare som produktägaren har angivit. Formatet eller längd på batchen stämmer inte med uppladdad batch. Ett larm har initierats i systemet.”
• New operation codes when the format or length of the serial number does not match:
  41020010, 41020011 and 41020012: ” Serienumret är okänt. Längden eller formatet stämmer inte med läkemedelsföretagets format. Ett larm har initierats i systemet.”

Other changes in release 14

• SMVS API 2.4 is set as deprecated but works exactly as usual until it is removed in the release planned for April/May 2025.
  NOTE: SMVS API version 2.3 will stop working in October/November 2024 and we recommend that end users who are on API 2.3 immediately switch to a later version. If you are not sure which version of the SMVS API you are using, you can contact e-VIS and we will help you with this.
• Further streamlined process for certification where IT suppliers and end users who have logged into the IQE environment will be able to upload test evidence, i.e. test book, screenshots, and log file directly in the SMVS IQE portal.
• e-VIS will be able to update certain information for an end-user location using the SMVS portal to be able to help support end-users. When a change is made, the end user’s primary contact will receive an email and can then log into the portal and approve/reject the proposed change.
• When a new location is created, e-VIS will be notified of this directly, which facilitates the periodic self-reporting that takes place periodically.
• Updated report for the Swedish Medical Products Agency regarding the audit trail of a pack.
• Minor changes that contribute to better usability, increased security, and system stability.

Information on functionality and current API versions, see Solidsoft ITE Developer Portal (https://developer-ite.nmvo.eu/).

Test environments

• ITE: SMVS Release 14 is available on ITE since February 19, 2024.
• IQE: SMVS Release 14 is planned to be available to test on the IQE environment after March 21, 2024.

2023-11-08

Release 13

The deployment started 7 November, 2023 at 23:00 and was completed 8 November, 2023 at 01:00 (CEST).
The release should have no impact on current connectivity. However, a new API 3.0 is being introduced, which e-VIS recommends that all end users start using as soon as possible.

Some important changes are:

New API version 3.0 is introduced. API 3.0 brings, among other things, the following changes that may affect the end-user system’s connection to SMVS for those who intend to start using the new API version:

• SMVS API version 3.0
  • The number of deactivation attempts is included in the response for a pack if it is already decommissioned, upon verification or another attempt to decommission the pack.
  • When an alert is created, a direct link to the Swedish alert portal (NMVS Alerts) is included in the response. To access the alert via the link, you need to log in to NMVS Alerts.
    More information about the alert portal and how pharmacies gain access can be found at the Swedish entry/Varningar och larm/e-VIS Alertportal – NMVS Alerts.
    According to agreement, all pharmacies and wholesalers in Sweden must have access to the portal by autumn 2023 at the latest.
  • New operation code “A0020000: Systemet kan inte svara på anropet just nu. Vänligen försök igen senare.” that correctly handles Internal Server Error responses to the client.

As usual, e-VIS recommends that end users use the latest available API version as soon as possible.

Other changes in release 13 are:

• Streamlined process for IT suppliers and end users who have a login to the IQE environment, by providing the opportunity to create test books themselves for testing and certification purpose (Qualification test book) on IQE.
• Option for end users to generate and view reports directly in the SMVS portal. The reports were previously available via the Report API but can now be generated directly via the SMVS Portal. This applies to the following reports:
  • Pack State Changes Client Report
  • Product Catalogue Data Client Report
  • Returned Packs Client Report
  • Transaction Log Client Report
  • Contracted Wholesalers Stakeholder Report
• Role based access control for client credentials that could limit permissions for pack state changes, verifications, and reports.
• Improved page in the SMVS portal for user management. For example. possibility to export the list of users.
• SMVS API 2.3 is set as deprecated but works as usual until it is removed in the release planned for Q4 2024.
• Updated and improved reports for the Swedish Medicines Agency.
• A few changes that contribute to better usability, increased security, and system stability.

Test environments

• ITE: SMVS Release 13 is available on ITE since June 9, 2023.
• IQE: SMVS Release 13 is planned to be available to use on the IQE environment after August 30, 2023.

More information about functionality and current API versions is found on the Solidsoft ITE Developer Portal: https://developer-ite.nmvo.eu/

2023-05-24

Release 12
Deployment started 23 May, 2023 at 23:00 and was completed 24 May 24, 2023 at 04:00 (CEST).

The main changes in release 12 are as follows:

• SMVS API version 2.2 is removed.
• User Agent header will be required for authentication API requests. The authentication API is versioned managed, so end user systems need to adapt to this regardless of which version of the Pack API is used.
  NOTE! Information has been sent out to impacted IT suppliers and end users where adaptation needs to take place.
• Ensure that the authentication API is compliant with the OAuth2 specification (4.1.2.1) if a client makes more than the allowed number of calls in 5 minutes. The response returns instead of an Operation Code and Warning after Release 12 the following response:
  • “error”: “temporarily_unavailable”
  • “error_description”: “Too many requests. Your account is limited to {numRequests} requests every {duration} seconds.”
    
• Other changes in R12 are:
• Updated and improved reports for regulatory authorities (Läkemedelsverket).
• Possibility for e-VIS to move a location from one organisation to another. Can be used for e.g. purchase of a pharmacy where the pharmacy permit and stock are included so that the packaging history is kept correct and intact.
• A number of changes that contribute to better usability, increased security and system stability, for example:
  • Upgrade to .NET 7 and use the latest stable versions of system libraries (libraries).
  • Use Azure Databricks in the reporting solution that currently uses Azure Data Lake Gen1 and Azure Data Lake Analytics.
• Test environments
• ITE: SMVS Release 12 is planned to be available on ITE from 7 February 2023.
• IQE: SMVS Release 12 is planned to be available to test on the IQE environment after March 14, 2023.

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.