Skip til primært indhold

IT STANDARD TERMS & CONDITIONS

These Terms & Conditions apply when Region Syddanmark (the Region of Southern Denmark) (the Customer) purchases medical devices with or without associated IT systems from a given supplier (the Supplier).

Parts of the below Terms may be omitted if the elements are not included in the Solution offered.

Definitions:

The Customer is defined as Region Syddanmark.

The Supplier is defined as the tenderer with whom the agreement is concluded.

The Solution is defined as the product offered by the Supplier. This may be stand-alone medical equipment, specialised computers, servers and/or client and server software.

The Solution must use public Danish and/or international standards (e.g., DICOM, HL7, ASTM, FHIR).

The Solution's user interfaces, and API must support character sets meeting the UTF8 standard or equivalent, and all Danish special characters – such as æ-ø-å and Danish comma and thousand separators – must be supported. The solution must also be able to handle Danish CPR numbers (Personal ID Number) with and without hyphens.

It is a requirement that there is a confidentiality statement and at times, also a data processing agreement from the standard template of Region Syddanmark. The confidentiality statement and a data processing agreement must be signed before acceptance of the order/contract.

The Supplier is required to comply with the requirements of MDR (the Medical Device Regulation) and IVD (the In-Vitro Diagnostics Regulation) as regards CE marking to the extent that the Solution (or parts thereof) is or will be subject to this legislation.

The requirements shall be implemented in the Solution as soon as possible in the light of the new MDR rules. The Supplier is thus obliged to give priority to rapid implementation thereafter.

 

Diagnostic imaging modalities and workstations must support at least the latest version of the DICOM communication protocol for exchanging information with other diagnostic imaging equipment such as RIS, PACS, film printers, workstations, etc.

The Supplier must be able to provide the DICOM Conformance Statement fully describing the DICOM implementation included in the Solution. The Conformance Statement shall comply fully with the guidelines for conformance claims as described by the DICOM standard. If any of the described DICOM functionality is provided as an option, it must be clearly indicated as an option.

AE titles of modalities must follow the Customer's regional naming standards and contain a maximum of 16 characters, Capital letters, numbers, and no special characters.

Data communication via HL7 or similar standard protocol is a requirement.

Region Syddanmark has a central platform for collecting patient and device data from medical devices called MDIC. If the Solution can export patient or device data, the Supplier shall, at the Customer's request, provide the API and documentation to Region Syddanmark as well as to the MDIC supplier, so that it will be possible to transfer patient and device data directly from the Solution to the MDIC platform.

It is a requirement that the Solution must always comply with the Danish Health Care Act, Legislative Decree of 2018-11-02 No. 1286, and subsequent amendments. Adaptations are handled according to the contract's change management.

It is a requirement that the Solution processes personal data in accordance with the EU General Data Protection Regulation 679/2016

(GDPR) effective from 25 May 2018, and subsequent amendments, the Personal Data Processing Act (Data Protection Act) Act of 2018-05-23 No. 502 on supplementary provisions to the Regulation on the protection of individuals regarding the processing of personal data and on the free movement of such data (and subsequent amendments). The practices of the Data Protection Authority regarding the processing of personal data must be followed and data must be processed in accordance with good data processing practices.

It is a requirement that the Solution allows the possibility of retrieving all data about an individual in the context of a request for access to documents as well as in the context of the right to be forgotten. In connection with the search, the Solution must support the possibility of searching all data sources including databases, files, logs, etc. on a given individual. The search must be able to specify an individual, a time period, types of data (e.g., documents or images), etc. 

It is a requirement that the Solution must support data protection through design and default settings (in line with GDPR Article 25), as well as security and privacy.

The Supplier must document an IT contingency plan for how a possible security incident is handled within the Solution.

It is a requirement that the Supplier and the Solution support and comply with the security requirements specified in the then current version of ISO/IEC 27001 and ISO/IEC 27701 or equivalent and that the Customer can monitor compliance with these on an ongoing basis.

It is a requirement that all data transport to and from the Solution shall be encrypted using the latest version of TLS.

The Customer regularly scans Servers, clients, and medical equipment for IT vulnerabilities. The Supplier is obliged to:

-  Approve and release continuously security patches for operating systems in the Solution within one month of release from the OS manufacturer (e.g., Microsoft).

-  Develop, approve and release continuously security patches for firmware and software in the Solution within 3 months of the request from the Customer.

Servers and clients within the Solution must be protected by Trend Micro Antivirus or similar via an installed agent. Servers must be monitored with Chef and Zabbix agent as a minimum. Clients must be instructed to install critical Windows updates.

The Solution will be implemented directly in the Region's network infrastructure and use IP addresses from there. Only by special agreement may the Solution include router/firewall solutions for routing between the Region's network and the Solution.

It is not permitted to make connections from the DMZ to the internal network of the Region, i.e., initiation of connections through the firewall may only take place from the internal network and not from the DMZ.

The Solution shall use TCP/IPv4 or IPv6 communication between servers, clients, and appliances.

If the Solution uses multicast, a Solution Proposal must be drawn up in cooperation with Region Syddanmark, Regional IT.

The Solution must be capable of operating fully on the Customer's existing WAN/MPLS network.

The Solution must use NTP time synchronisation via lookups in the Region/Hospital NTP Service.

The Solution must use DNS for looking up names for servers and systems. IP addresses cannot be used as there is no guarantee that they will remain the same.

Closed VLANs for systems (internal DMZ) can be created if desired.

The Solution must support 802.1x authentication on MAC address in relation to VLAN.

The Solution MAC address(es) for wired or WIFI network must be provided to the Customer at installation. 

The Solution will be connected to the medical network without Internet access. If Internet access is required, destinations must be specified (IP, URL, ports).

The host name(s)/computer name(s) of the Solution must be named at installation by the Customer according to the following standard "MT [device number]".

This requires that workstations and appliances included in the Solution must use existing Medico network VLAN and CISCO switches.

The Solution must be equipped with a Standard Ethernet Interface with support for 10/100 or 10/100/1000 Mbit/s in relation to wired networks with RJ45.

Patch cables for wired networks shall be category CAT6a STP/FTP or CAT6 UTP and be green and LSZH halogen free.

A system diagram (draft format accepted) describing all the network components of the system, including server connections, remote support, firewalls, etc., must be submitted at least five working days before connection to the network.

The Solution will use the Customer's existing Medico WI-FI network WLAN and CISCO Access Point for wireless connectivity.

The Solution must be configured with dynamic channel switching on 2.4Ghz and 5Ghz. Fixed channel selection requires a special agreement with the Customer.

The Solution must support 802.1x authentication key with validation type PEAP-MS-CHAPv2 in relation to WIFI. Service user and password are to be provided by the Customer at the installation.

The Solution must support WPA2/AES encryption.

The Solution must support 802.11a/g/n at 2.4GHz and/or 802.11ac/ax 5 GHz with WI-FI 6 technologies.

The Solution must use the Customer's SSID when connecting wirelessly to the Medico network.

Mobile devices with WIFI must include a description with information on transmit power, offset and roaming on 2.4GHz and 5GHz.

It is a requirement that the Supplier can access the Solution located in the hospital network via connection to the hospital network. The connection must, at the request and acceptance of Region Syddanmark, be:

-  an external VPN user access to Region Syddanmark or

-  a VPN Site-to-Site connection.

This requires that the Supplier's service access to the hospital network will be via the Region's Firewall. The service connection must therefore be able to support any restrictions that a Firewall may place upon it.

No remote login tools may be installed on the servers. Please refer to the Region's guidelines that all remote access must be through tools provided by the Region, including VPN access for external users.

Remote login on the servers must be done only with personal AD external user and it is the responsibility of the Supplier to keep external users active so that they can be used for remote access. After three months, access for the user will be automatically closed if there has been no login.

The Supplier must use Region Syddanmarks support tool https://support.rsyd.dk for remote support together with a personal user account. If other remote support is used, it must include logging and 2-factor authentication and be approved by the Customer.

Servers must be able to run in the Customer's existing IT environment for the duration of the contract.

Servers must be run as virtual servers in the Customer's VMware environment. If there are circumstances that make it impossible / inappropriate to run the server as a virtual server, a physical server may be used.

Virtual servers with more than 16 vCPU cores and 128GB RAM are not recommended. Larger servers than normally incorporated by CPU and RAM or additional storage requirements (more than 1 TB over 4 years), must be agreed with the Customer.

Servers must be run from the Customer's data centres in Kolding.

The Customer purchases servers at the Supplier's expense.

Servers shall support Windows 2019 Datacenter 64 bit, Redhat Enterprise 7/8 latest build, Ubuntu 18.04/20.04 LTS or CentOS 7/8 latest build, and shall follow the development so that the Customer is never tied to operating systems that are "End Of Life" or "End of Support.

SQL databases must support min. MS SQL Server 2017/2019. The Customer uses Microsoft SQL hotel with MS SQL Server, and must follow the development, so that the Customer at no time becomes tied to databases that are "End Of Life" or "End Of Support”.

Drives for the operating system must not be used for application installation or as storage for application data. This must be done on another drive, alternatively a CIFS/DFS share.

The Solution must be designed so that the Customer can perform automated Patching of the OS without data corruption or data loss within the Solution. This means that:

Application servers in the Solution shall shut down the application safely when the server is restarted from the operating system and when starting application servers, the application shall start up automatically when the servers (OS) are started.

The Solution shall be built redundantly so that the Solution is fault tolerant and can be run from the Customer's operations centres, so that Patching can be performed without affecting availability.

Servers must always be with Active Directory, domain joined for MS Windows and LDAPS integration for Linux.

Service users must not be granted Administrator rights on servers and must not be used to log on to servers. Service users can be created as needed for use. Managed Service Accounts (MSA) should be used where possible.

Application services/services on servers must run under a service user from AD and must not run Services under standard AD users.

All login on servers must be done with a personal account from AD. Please refer to the Region's guidelines that all logins must be verifiable in AD.

Installation of applications on servers must be possible on an AD-integrated server. There should be no need to log out the server of AD and back in again in order to perform the installation. Installation of applications with local users is not possible.

Websites that use login information must be accessed via SSL. Websites must by default be SSL offloaded via NetScaler.

Group Policy (GPO) can be created for specific functions that vendors need to set up to guarantee set-up. In this instance, local firewall on servers is an option.

It is the role of the vendor to describe/document which services must be monitored on the server, as well as looking into log files and checking the age of the files.

It is the responsibility of the Supplier to provide security updates for operating systems outside of Windows. The Customer’s IT will perform this at least once a year.

The systems must be able to withstand a weekly security scan, in accordance with the IT Security Policy.

Change Management is a requirement on servers in the production environment but may be waived on servers in the staging environment.

Restricted Vendor Access (RLA) is preferred where possible.

Installation of systems where the OS or associated applications are being phased out or are out of Main Support from the vendor should be avoided in new installations, otherwise upgrades will be required shortly after servers are commissioned.

Vendors who want to use docker containers are encouraged to make applications small with connectivity to CIFS and SQL hotels, as it is not recommended to store data in docker containers. The Customer’s IT has an environment to run docker.

The Supplier is responsible for preparing documentation of the Solution including a technical operation manual. The documentation must be complete in relation to the ordering of servers and the subsequent operation and monitoring of the Solution.

The Supplier undertakes to include a drawing of the servers and databases included in the Solution (e.g., Visio drawings), so that an overview can be formed between the operational interfaces, dependencies, integrations, and components used in the Solution description.

 

 

It is a requirement that the Supplier specifies the storage (disk space) requirements for the operation of the Solution, broken down as appropriate by, for example, operating system, basic software, data, etc. The specification shall include the baseline storage requirements and the expected development of the requirements as the use of the Solution increases.

It is a requirement that the Solution uses the Region's SAN installation for permanent data storage – and thus not the disk space internally on servers or on separate, dedicated disk systems.

It is a requirement that the Supplier describes proposed backup routines and policies.

It is a requirement that the Supplier illustrates how the running of backups affects the availability of the Solution.

Network shares on servers must be delimited with access only for those users who need access. AD groups can be created for this if requested. Domain Users are not an AD group that may be used on network shares.

Client applications within the Solution used via a browser must, as a minimum, support Edge, Internet Explorer v.11, Firefox v.91 or Google Chrome v.94 or later.

This means that applications within the Solution must be able to run on supported operating systems. The Customer uses Windows 10 Enterprise SAC 64 bit, but updates continuously as Microsoft releases new builds.

Platform products and operating systems, databases, browsers, and other 3rd party products that the Solution uses must keep pace so that the Customer is never tied to products and operating systems that are "end of life”.

If the Solution uses 3rd party applications, the Solution must, at any time, be able to handle that these are updated to the latest version. For example: Java, or Acrobat Reader.

Client applications in the Solution must be able to work on a standard PC and ESA (Citrix) solution without administrative rights.

The Solution must be able to perform transaction logging on relevant events, which includes user events, events from other subsystems in accordance with applicable laws and regulations. This means to say that there must be full traceability of all transactions and records.

This requires compliance with the Data Protection Regulation. There must be mechanical recording (logging) of all uses of personal data. The record must as a minimum contain information about the time, the user, the type of use and the indication of the person to whom the data applied, or the search criterion used. The log shall be kept for 6 months, after which it shall be deleted. Authorities with a special need can keep the log for up to five years. Read more about it on the website retsinformation.dk

The technical solution for logging  must, as a minimum, be able to generate log events via standard methods and ensure the integrity of log data. It must also be possible to transport log data dynamically via pull/push to a secondary system.

The Solution must log relevant events in the Solution and shall provide an extract of the transaction log, audit log and system log.

Windows and Linux servers shall log warning, error, and critical events in the event log. The audit log shall be stored in the Customer's own database.

 

It requires that the Solution's IT systems, where patient data is accessed, shall require the use of a username and personal password. Login information must be stored in a log file, and must as a minimum contain username, date and time.

User access to the Solution shall be differentiated so that different users/user groups can have rights to different parts of the Solution and different rights within each part (query, add, edit/modify, delete, etc.).

The default user login and password must be changed to min. 10 characters in lower and upper case and contain numbers.

User management on clients with user ID/password authentication must be done via Region Syddanmark AD (Microsoft Active Directory) with LDAP.

If user login supports Single Sign On (SSO), authentication of user ID and password must be done via Region Syddanmark AD (Microsoft Active Directory).

Shared users are not allowed, and no local users may be created on the servers.

Authentication of users in the Solution is based on local login in AD, (Active directory). The Solution must accept user login and user rights depending on the desired roles with AD groups.

The Solution shall provide role-based user management and access control, where authorisation (granting of informational and functional rights) is based on roles. The Customer must approve the final role-authorisation model.

The Supplier shall prepare and maintain a description, of the Solution's agreed role access control, as part of the Solution's documentation.

The Customer's change process including deadlines, approvals, and CAB processing must be respected at all times, as is the case for the Customer’s veto rights on changes in the Supplier's systems.

The Supplier must document all system dependencies and integrations both in writing and in architecture drawing(s).

The Supplier shall, in cooperation with the Customer, prepare system documentation of the Supplier's and the Customer's area of operational responsibility. It is a requirement that a design drawing is included.

 

APPFWU02V