Environments
Excerpt
The eHealth system has separate environments for testing and production use. These environments help developers build, test, and launch eHealth solutions. Here's what each environment offers, who can use it, how to access it, and how it connects with other systems.
Who this is for: This guide is written for outside companies and developers who want to understand the basic setup of eHealth environments. It explains what each environment does, who uses it, how to get access, and how to connect with other systems. This information enables partners to work together more effectively within the eHealth ecosystem.
- 1 Excerpt
- 2 Operational Environments
- 2.1 Internal Test Environment
- 2.1.1 Characteristics
- 2.2 External Development Environment (devenvcgi)
- 2.2.1 Characteristics
- 2.3 External Test Environment
- 2.3.1 Characteristics
- 2.3.2 Stable Integrations
- 2.4 Pre-production Environment
- 2.4.1 Characteristics
- 2.4.2 Stable Integrations
- 2.5 Production Environment
- 2.5.1 Characteristics
- 2.1 Internal Test Environment
- 3 eHealth Environments' External Connection
- 4 External System Connections
- 5 List of eHealth environments
- 6 Actors in the eHealth Environments
- 7 Accessing the environments
- 8 Components and Data Lifecycle in Environments
Operational Environments
The operational environment is divided into four independent environments for use in operational execution of the Infrastructure, as well as for use in the Internal Tests and External tests.
The operational environment is the IT environment that Systematic uses for the operation and maintenance of the Infrastructure and consists of several independent environments:
Environement | User for | Person data (both real credentials and data about real employees, as well as credentials and data about real citizens.) |
|---|---|---|
Internal Test | Exclusively for conducting Internal Tests | No |
External Development Environment | Development by Application System Suppliers and Third-party Software Suppliers | No |
External Test | Testing by Customer, Application System Suppliers and Third-party Software Suppliers. | No |
Preproduction | Exclusively for conducting Internal Tests. | No |
Production | Operational execution of the Infrastructure | Yes |
Education | Training of end users by Application System Suppliers and Third-party Software Suppliers |
|
The environments are established so that they are compliant with applicable rules in connection with the processing of personal data.
Internal Test Environment
In the Internal Test Environment, relevant Tests are conducted by Systematic.
Characteristics
Test environments cannot contain personal data, and are therefore not limited by which country or area they are operationally executed in.
External Development Environment (devenvcgi)
During the contract, an additional environment was established for early development and testing of Application Systems integration to the Infrastructure's services for their own development and testing purposes. (see CCR0001).
However, during the project execution, this has changed to have the same versions as the external test environment.
The operational environment is expanded with an additional dedicated environment specifically designed to address critical schedule constraints and third-party integration requirements.
Characteristics
This environment cannot contain personal data, allowing it to operate in any country or region without geographic restrictions.
The environment runs as an independent instance of the Infrastructure with early beta access features for pre-release testing.
Test Data Management Application Systems vendors have control over their test data, including the ability to create and modify datasets according to their specific testing needs and schedules. No coordination with other parties is required.
Capacity and Integration The environments support:
Concurrent testing by multiple Application Systems vendors
Integration with vendor application test systems and external testing tools
Early Access Vendors receive early beta access to begin preparatory testing before the official release date. This access operates under controlled conditions with proper change management processes to maintain stability and reliability.
Vendor Autonomy The environments maximise independence for third-party vendors, enabling them to manage their own testing schedules, test data, and procedures without requiring detailed coordination with other parties.
External Test Environment
The purpose of the External Test Environment is to give authorities and Application Systems access to use the Infrastructure's services for their own testing purposes.
Characteristics
Application Systems can obtain access to the Infrastructure in the External Test Environment from external networks.
Test environments cannot contain personal data, and are therefore not limited by which country or area they are operationally executed in.
The External Test Environment must be able to connect to appropriate data networks within the healthcare area, particularly the Health Data Network.
Stable Integrations
The environment uses identical interfaces and APIs as in the Production Environment. This ensures that integrations remain stable and reliable during testing in the External Test Environment.
For external integrations, the environment is connected to external test environments and systems.
The only difference is in system sizing and capacity.
Pre-production Environment
The Pre-production Environment is used to conduct relevant Tests.
Characteristics
The Pre-production Environment is, software version-wise, a copy of the Production Environment.
There is no requirement that the Pre-production Environment be dimensioned for the same load and redundancy as the Production Environment.
In connection with internal tests, it is used to demonstrate that Service Targets, including response times for the Infrastructure in the Production Environment, are met.
The Pre-production Environment is operationally executed according to requirements for the protection of personal data.
Stable Integrations
The environment uses identical interfaces and APIs as in the Production Environment.
For external integrations, the environment is connected to external test environments and systems.
The only difference is in system sizing and capacity.
Notice, PREPROD uses KIH TEST. That is, the pre-production is connected to environments at NSP that do not allow personal data. Therefore, it is currently not possible to have personal data in pre-production.
Production Environment
The Production Environment is used for the execution of the Infrastructure with production data.
Characteristics
The Production Environment is secured to ensure that the Infrastructure can be operationally executed according to the requirements, including protection against unintended and unauthorised access to data, configuration, and logged information within the Infrastructure.
The Production Environment is operationally executed by requirements for the protection of personal data. The Production Environment can therefore be operationally executed within the EU, provided that appropriate security measures are observed.
The Production Environment must be scalable so that the Delivery Agreement requirements are met under Infrastructure load, and thus be able to handle peak loads that exceed the expected load level.
The Production Environment connect to appropriate data networks within the healthcare area, particularly the Health Data Network.
eHealth Environments' External Connection
Overview
This document provides a comprehensive mapping of eHealth environments and their connections to external systems, with a focus on document sharing integrations.
Environment Types
The eHealth platform consists of six distinct environment types:
Environment Type | Environment Code | Purpose | Sundhedsdatanettet (SDNv4) |
|---|---|---|---|
Internal test environment |
| Internal development and testing |
|
External test environment |
| External partner testing | Yes |
Vendor development environment |
| Third-party vendor development |
|
Education environment |
| Training and educational purposes |
|
Pre-production environment |
| Production readiness validation |
|
Production environment |
| Live operational environment | Yes |
The following diagram illustrates the connections between the environments and external systems in a graphical format. Not all integrations are displayed, but focus on the integrations related to document sharing.
Sundhedsdatanettet (SDN)
The Danish Health Data Network (Sundhedsdatanettet) is the secure national network used for exchanging sensitive health data between authorities, regions, municipalities, general practitioners, hospitals, pharmacies, and other actors in the Danish healthcare sector.
Two environments are connected to the Sundhedsdatanettet through an SD WAN (Software-defined WAN). It is FUT-S that decides which eHealth environments are connected to SDNv4.
It is also FUT-S that manages service agreements between eHealth and the actual NSP services; e.g. MinLog2, NAS, STS, DDS, KIH….
See also:
External System Connections
Authentication and User Management Systems
NemLogin, KOMBIT, and SEB Connections
All non-production environments connect to test systems, while production uses live services:
Test Environments (INTTEST, EXTTEST, DEVENVCGI, TEST002, PREPROD):
NemLogin:
test-nemlog-in.dkKOMBIT Adgangsstyring:
adgangsstyring.eksterntest-stoettesystemerne.dkSEB:
http://t-seb.dkseb.dk
Production Environment (PROD):
NemLogin:
login.nemlog-in.dkKOMBIT Adgangsstyring:
adgangsstyring.stoettesystemerne.dkSEB:
http://seb.dkseb.dk(Production environment)
KOMBIT Systems
FK Organisation Service
Test Environments (INTTEST, EXTTEST, DEVENVCGI, TEST002, PREPROD):
Endpoint:
organisation.eksterntest-stoettesystemerne.dk
Production Environment (PROD):
Endpoint:
organisation.stoettesystemerne.dk
NSP (National Service Platform) Integration
NSP Test Environments
NSP provides multiple test environments with different endpoints for municipalities (cNSP) and regions (dNSP):
NSP Environment | Municipalities Endpoint | Regions Endpoint | KIH Availability |
|---|---|---|---|
TEST1 |
|
| Not available |
TEST2 |
|
|
|
PRODTEST |
|
|
|
UDD |
|
|
|
Document Sharing Service Paths
All NSP environments use paths for document sharing services:
DROS Paths:
/dros/iti41,/dros/iti57DDS Paths:
/ddsregistry,/ddsrepository
Service Endpoints by eHealth Environment
Health Environment | NSP Environment | Document Repository (ITI-41) (Through NSP decoupling) | KIH Repository (ITI-41) | Registry (ITI-18) (Through NSP decoupling) | Repository (ITI-43) (Through NSP decoupling) | Metadata Update (ITI-57) (Through NSP decoupling) |
|---|---|---|---|---|---|---|
INTTEST | NSP TEST2 (Central) |
|
|
|
|
|
DEVENVCGI | NSP TEST2 (Central) |
|
|
|
|
|
EXTTEST | NSP TEST2 (Central) |
|
|
|
|
|
TEST002 | NSP TEST2 (Central) |
|
|
|
|
|
PREPROD | NSP PRODTEST (Central) |
|
|
|
|
|
PROD | NSP PROD (Central) |
|
|
|
|
|
Note the following differences:
EXTTEST Exception: Uses KIH UDD over Secure Data Network (SDNv4)
PREPROD Exception: Uses KIH TEST environment despite being connected to NSP PRODTEST
Integration Standards
All document sharing integrations follow IHE (Integrating the Healthcare Enterprise) profiles:
ITI-18: Registry Stored Query
ITI-41: Provide and Register Document Set-b
ITI-43: Retrieve Document Set
ITI-57: Update Document Set
Additional External Resources
List of eHealth environments
- eHealth Infrastructure Environment: Internal Test (INTTEST) — INTTEST is used by Systematic for internal testing of the latest builds on the eHealth Infrastructure.
- eHealth Infrastructure Environment: Development Test (DEVENVCGI) — Development environment for application vendors - third parties developing solutions that use the infrastructure.
- eHealth Infrastructure Environment: External Test (EXTTEST) — The customer uses the EXTTEST environment for testing stable builds, and telemedicine solution providers use it for cross-vendor testing when integrating their solutions with the eHealth Infrastructure.
- eHealth Infrastructure Environment: Education (TEST002) — The customer and telemedicine providers use the TEST002 environment for training their end users.
- eHealth Infrastructure Environment: PREPROD — The infrastructure provider uses this environment to test and trace issues in production-like conditions. It is also used for load-testing new releases before production deployment.
- eHealth Infrastructure Environment: PROD — Production environment
The environment for KL Gateway is described here: KL Gateway environments
Actors in the eHealth Environments
A breakdown of the different actors and their roles within the eHealth environments:
Development Team
Infrastructure Development Teams: Responsible for developing the platform and eHealth services.
Telemedicine Solution Provider: Engaged in the development of Telemedicine Solutions.
Test Users: Users used for testing Telemedicine Solutions and the eHealth Infrastructure. Test users can be used by:
Telemedicine Solution Providers: Test the Telemedicine Solution integration to the eHealth infrastructure, primarily in the External Test Environment (EXTTEST).
Customers: Tests the eHealth infrastructure primarily in the External Test Environment (EXTTEST).
Infrastructure Provider: Tests the eHealth infrastructure primarily in the Internal Test Environment (INTTEST).
End Users: Individuals who currently use or intend to use Telemedicine Solutions for their healthcare needs.
Operation Teams
Infrastructure Operations: In charge of operating the eHealth infrastructure, specifically deploying to PRODUCTION.
Telemedicine Solution Provider: Responsible for operating the Telemedicine Solution and deploying Telemedicine Solutions to PRODUCTION.
The diagram below visually depicts the various actors, end-users, solution developers, and operations utilising and accessing the eHealth infrastructure environments.
Accessing the environments
The end user and test user log in to the eHealth Infrastructure involves the following external systems:
Nemlogin: Used for the federated login of Citizens.
SEB: Utilised for federated login purposes by Employees in regions and municipalities.
KOMBIT STS: Employed for federated login by Employees in municipalities.
The process for logging in follows a specific flow, which is detailed across the following pages:
Components and Data Lifecycle in Environments
The diagram below provides a visual overview of the lifecycle of components and data within the eHealth infrastructure environments.
The diagram outlines the progression of components as they are promoted through different environments as part of the release and deployment process.
The diagram also depicts the mechanisms for exporting and importing data across these environments.
Component Promotion: The diagram illustrates the progression of components through various environments, showcasing how they are promoted across different stages within the eHealth infrastructure.
Data Export/Import Process: The demonstrates the data flow, highlighting the export and import procedures between different environments. Packages (such as questionnaires, activity definitions, and plan definitions) follow a distinct flow. These packages can be developed or created in the EXTTEST environment, exported from there, and subsequently imported into the PRODUCTION environment, and vice versa.
The Test Environments currently have no data retention mechanism; that is, the test data are not automatically restored to a known baseline.